Search Results

Dear Nino, Thank you for suggesting the RTTViewer, thank you for providing this tool, it is great because it allows to have terminal output with a plain JLink during a debugging session. However I have noticed a few issues : - On MACOS, it crashes when I go into the menu « Logging» / « Channel infos…» - Not really a big issue, but a nice-to-have, one cannot configure the character encoding for display (just for display, of course for the logging itself the log shall remain as such), it seems to …

I understood what was happening by setting dynamically a watchpoint from the target app, and finding that it was not hit : this was not a memory corruption but some real time problem (reading some data not yet ready). This thread was helpful to me : devzone.nordicsemi.com/f/nordi…-a-watchpoint-dynamically I found that my watch point was not hit by polling the match bit in DWT->FUNCTION and logging it over RTT. Good to know that the start/stop trace use the DWT, by chance I hadn't them configured…

It would be nice to have a terminal option to enable color support, like « ESC [1;31m » to get red front color, and « ESC [0m » to go back to default colors. The ESC word denotes the character with ASCII code 27'd, a.k.a 1b'h, a.ka. CTRL [.

Dear Nino, After digging in the Arm Cortex M4 documentation, and in the Arm V7M manual I found that the DWT is actually programmable through registers visible in the FW addressing space. So I intend to use that by hacking my FW to dynamically program some watch point. I am wondering however whether that may cause any conflict with Ozone / JTrace Pro debugging. * If the FW configures some watchpoint dynamically and the watchpoint is hit, will this be visible in Ozone ? * if on the other hand I ma…

Dear Nino, Thank you for your kind reply. I actually stopped using the data sampling when using also instruction trace. I had the impression that, although I had configured the sampling at 500Hz that was taking too much throughput and I was getting incomplete traces. Please note that the nRF52840 has its ETM trace port clocked at 1/4 CPU speed rather then 1/2 as usual. I got this impression because going upwards in the instruction trace caused some 8 second leap in the timeline, which seems incr…

I am trying to use data sampling in order to locate more finely in the instruction trace where the corruption occurs. However, that is not easy : I know in advance that the corruption will occur at a couple of possible addresses, but I don't know in advance what value is going to be overwritten, I know it only afterwards by the terminal printf trace. Also the corruption condition does not last very long, I could catch it with data sampling frequency of 10kHz, and the condition lasted 5ms. I made…

Dear Ozone expert, I am debugging an application running on an nRF52840 Nordic chip with FreeRTOS embedded OS. I would like to locate where some memory corruption is occurring. I have roughly located conditions happening before and after the corruption itself : so I know that the memory corruption is occurring after some function before_corruption() has been called and has returned, and before I call some SW triggered breakpoint on which the Ozone trace stops. So, I have all the instruction trac…