#Why use trace
"Embedded Trace Macrocell (ETM) allows to capture information on the processor’s state without affecting the processor’s performance. Microcontrollers that include an ETM allow detailed program execution to be recorded and saved in real time. This information can be used to analyze program flow and execution time, perform profiling and locate software bugs that are otherwise very hard to locate. A typical situation in which code trace is extremely valuable, is to find out how and why a "program crash" occurred in case of a runaway program count." J-Link/J-Trace User Guide.
Debugging features can be classified into two groups.
Tracing is a form of Noninvasive debugging, and on nRF52 series devices there are three types of trace sources:
The trace information is connected to the Trace Port Interface Unit (TPIU) and exported to external trace hardware (i.e. SEGGER's j-Trace external debugger).
IMPORTANT: To use trace you need to have an external debugger that supports trace (trace won't work using the on-board debugger on our development kits). https://www.segger.com/jlink-debug-probes.html (see debug probes with built-in trace memory). IAR and ULink also offer debuggers that support trace and work with our devices.
#Embedded Trace Macrocell (ETM)
ETM allows you to observe how your software executes on the target device. ETM will be useful when debugging and optimizing your embedded system. When using conventional debug techniques there are some disadvantages: intrusive (behavior of the system is changed), non real-time, and no performance visibility. With trace, instruction and/or data transfer is collected and delivered off-chip in real-time (or stored on-chip for post processing).
Main benefits of ETM:
#Setting up and using ETM
The connector board schematic.
From here just play around, see what trace is all about, and post what you find/any questions/concerns you may have in the comments!
I'm no expert here, so please share your experiences with trace. How has it been useful? What else could be said about trace? Feel free to offer suggestions about how I can improve this post either in the comments or a PM.
Sorry to kick this topic, but did you ever found out why oZone stopped in bluetooth connect? I see something similar where the SD fetches from a non-existing table that it expects at 0x20000000. That address is RAM, but it is uninitialized (never written to) before it is accessed.
I just purchased the J-Trace Pro Cortex from Segger. It has a 19-pin interface so you won't need the adapter.
Thank you so much for your blog post. It just so happens that I am currently investigating ways to access TRACE on a nRF52832 DK.
Thus, I am currently choosing what debugger to buy. From my understanding of your article, I could achieve what I am trying to do with the following:
1: J-Trace Pro Cortex- M - www.segger.com/.../
2: J-Link 19 Pin Cortex-M adapter - www.segger.com/.../
3- Some custom wiring to reproduce the scheme you have detailed in your post.
Is that it ? I just want to make sure that I am not missing anything before going for it.
Thank you very much in advance !
The onboard debugger supports everything on the 10 pin cortex debug header, which includes SWO (P0.18) and nRESET (P0.21) which are routed to the correct pins, so output from the ITM and DWT can be captured via SWO. The 4 TRACEDATA pins however don't go anywhere, so you if you want to use those you need a capable debugger, like one of the Seggers with Trace (out of my budget).
Technically it's supposed to be possible to configure the TPIU to SWO mode but not bypass the formatter, so multiplexing ETM data onto SWO as well. That's probably not actually practical as a 1-bit wide trace port wouldn't be able to handle the data. I also have some doubt whether any IDE would expect formatted data out of SWO and handle it properly. If I get bored one day ...
I just checked to see that Segger Embedded Studio, like Crossworks, has the Instrument Functions option which sends ITM stimulus to channels 30 and 29 and does rudimentary function tracing. There's another couple of ITM channels it recognises, 0 is printf() style, 28 is program counter values and 31 is thread scheduling. I don't know what writes to 28 or 31 nor what format channel 31 expects, probably the Crossworks Tasking Library (their RTOS) uses it.
I suspect there are lots of cool things you can do with SWO and cheap trace units tend to support it where they don't support TRACE. Even CMSIS-DAP, ARM's own debug interface, only just supports SWO and doesn't support TRACE yet.
KLWP: That's a very good point. Some trace functionality is availalbe without an external debugger like J-Trace or ULink 2. I will look into this and post exactly what can be used with the on board debugger, but for now I think it is only ETM that requires an external debugger.