Search Results
Search results 1-6 of 6.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Thank You, I can confirm this issue has been resolved in Ozone 2.56f. Best Regards, Alessandro
-
We also (in my company) use Rust and Ozone as a debugger. It is true, watch data types and watch expression are not supported, however the rest seems fine. Ozone seems to have trouble recognizing data types sizes. The Global/Local Data successfully recognizes rust variables. If you want to check the value of the data you have to right click and check the variable value in the memory browser itself. You can also recognize rust functions and files in the source and function viewer. I suppose this …
-
Hello, I've tested again this in Ozone v2.56e. The issue has been successfully resolved (as noted in Ozone's Release Notes). Thank you for your support, Alessandro
-
Thank you! Regards, Alessandro
-
Hello, I am currently using: - Ozone 2.56e on Linux with the JLink DLLs 6.30h; I have an issue where if I am to compile an ELF with DWARF4 instead of DWARF3 (in TI Code Composer Studio), Ozone, either doesn't show debug symbols, either it displays a list of errors of the kind "ElfLib: libdwarf: Line info section too short in func _dwarf_lineno_init (offset, 0x...)". forum.segger.com/index.php/Attachment/2404/ I thought that it was my compiler having issues until I tried to debug the exact same b…
-
Hello, I am currently using: - Ozone 2.56c on Linux with the JLink DLLs 6.30d; - TMS570LC4357 on the XL2-570LC43(A) development board; - JTAG @1 MHz with semihosting Off and RTT Off; - No custom JLink scripts; I have an issue where from time to time I am having problems whenever the ARM assembly "SVC #" instruction is called. Whenever I reset and continue, Ozone will break at 0x08 (ARM SVC vector) even if I didn't put a breakpoint there. I've read that Semihosting uses the SVC location in order …