Search Results

Hi ToBoMi, it might well be the case that the break unit in your target hardware does not trigger on accesses on peripherals. Could you please check the specifications of your device whether data break points on peripheral registers are supported? Best regards -- AlexD

Hi GlebPlekhotko, we are not aware of such issues with the terminal window. Are you able to reproduce the issue on an eval board and provide a reproducer? The reproducer should encompass the ELF file, the Ozone project file and, of course, the information on which eval board this can be reproduced and a step-by-step description of how to reproduce the issue. If you are able to provide that information, please open a ticket in our support ticket system. Best regards -- AlexD

Hi chrishock, we need to be able to reproduce the issue locally for a proper analysis. So a video might not be too helpful here: It would show things on your machine but still not give us information allowing an analysis. During my investigations in particular I looked into the timeline window. I've seen the cursors following the mouse cursor smoothly, and the context menu opening with a delay comparable to the delay when opening a context menu in the finder. Best regards -- AlexD

Hi GlebPlekhotko, thank you for your post. We are aware of that and will provide a fix in one of the next Ozone releases. Best regards -- AlexD

Hi chrishock & akohlsmith, I just tried to reproduce the issue on... ...a MacBookPro (2016), macOS Monterey 12.7.2 ...a MacBookPro (lat 2013), macOS Big Sur 11.7.10 I observe a delay when opening a context menu in Ozone which is in the same range as when opening a context menu on the desktop. So I cannot confirm that such an issue exists. Could you please provide details on how to reproduce? Best regards -- AlexD

Hi! Good to see you're up and running again. Best regards -- AlexD

Hi bpantal, there is no such API call. Best regards -- AlexD

Hi Ewout, you may use the "source files" window (see section 4.19 in the Ozone User's Manual) to locate your file more rapidly, as the contents of that window can be sorted by clicking onto the respective table header as desired. You may also make use of the "quick find" widget (see section 3.11.16 in the Ozone User's Manual) that you can open via [ctrl]-[k]. By typing the first letters of the desired files you can easily reduce the size of that list, allowing you to rapidly narrow down the sear…

Hi Ewout, thank you for your suggestion. Sorting that list is not yet possible. I will add that to our internal list of future improvements. Best regards-- AlexD

Hi tzan, good to hear you are up and running again. Best regards -- AlexD

Hi Tzan, could you please check if the issue persists with the latest version of Ozone? Did you take heed of the suggestions you already received in the old thread you referenced? Probably your device has a boot loader. For debugging devices with a boot loader, please have a look at this WIKI page: wiki.segger.com/Debug_on_a_Target_with_Bootloader. Since you are also intending to debug RAM code, please also have a look at this WIKI page: wiki.segger.com/Ozone_Debug_and_Trace_with_RAM_Functions. …

Hi skam, actually, this should work. I guess, reason you did not see it working, might be that I specified "/" as a separator. Instead it should be ".", as you can see in the documentation of that command, which can be found in section 7.9.17.3 in the Ozone user's manual. Best regards -- AlexD

Hi skam, could you please provide an Ozone log and a J-Link log for the case that the memory window is not updated while the debug session is active? It might be the case the window is actually updated but if the memory content does not change, there will be no change in the display. Creating an Ozone log is described in section 8 of the Ozone user's manual, creating a J-Link log is described here: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Please note that both logs should be recorded in…

Hi skam, for an overview on the different trace types, please also have a look at this WIKI page: wiki.segger.com/General_information_about_tracing In case your chip does not support ETB, this feature is not available to you. Which device are you working on? It is quite likely that ETM is supported by your device, this would allow you to make use of pin tracing, but also requires you to utilize a J-Trace probe. Best regards -- AlexD

Hi skam, thank you for your suggestion to add support for scaling in the range less than 1. I'll bring that up in our next internal meeting. I cannot tell if or when this will be implemented, though. Best regards -- AlexD

Hi skam, this is intended. Hex numbers are normally interpreted as unsigned, however in the graph window numbers are considered being signed. Best regards -- AlexD

Hi Skam, often there are multiple ways to achieve a desired effect. Since your peripheral registers are memory mapped they may be accessed like memory. That's why reading the memory location works as well. The script you create is less portable, though. While the same register may exist in another MCU it might reside at a different address. By using the path name in Target.GetReg() allows your script to execute fine on another MCU, while accessing the memory address may cause tedious update of c…

Hi skam, the memory window does not update its content while the target is halted. This is intended. Automatic update only takes place when the CPU is running. Best regards -- AlexD

Hi skam, ETB is a hardware feature. The respective trace buffer is a buffer that is written by HW only. It is also a dedicated buffer and you cannot use another buffer, e.g. a RAM area, such as the RTT buffer. RTT is a software feature. You can do some software tracing, but not on instruction level. Systemview makes sophisticated use of that feature. General information on tracing, including descriptions of multiple trace types, can be found here: wiki.segger.com/J-Trace#General_information_abou…

Hi Skam, please be a bit more specific. At which occasion do you expect the refresh to occur? Best regards -- AlexD