Recommended
Related

Debugging nRF52 series devices using Trace

Michael Dietz

#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.

#Overview

Debugging features can be classified into two groups.

  1. Invasive debugging (i.e. program halt and stepping, HW breakpoints, etc...)
  2. Noninvasive debugging (i.e. memory access, trace, profiling)

Tracing is a form of Noninvasive debugging, and on nRF52 series devices there are three types of trace sources:

  • Instruction trace: Generated by the Embedded Trace Macrocell (ETM).
  • Data trace: Generated by the Data Watchpoint and Trace (DWT) unit.
  • Debug message: Generated by ITM, provides message output such as printf in the debugger GUI.

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)

http://www.arm.com/products/system-ip/debug-trace/trace-macrocells-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:

  • Trace and debug your system executing in real-time.
  • Collect vital timing on program execution for performance optimizations and ‘always-in-time’ code verification.
  • Capture program activity around the event you want to look at.

#Setting up and using ETM

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/dif.html#debugandtrace

  1. Connect debugger (with trace functionality) to target device, making sure trace pins are connected (see which GPIOs are trace pins here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/pin.html#pin_assign). Note that we have a custom board to make this easy but you will have to figure something else out.

The connector board schematic.

image description

  1. Make sure you have up-to-date startup files and define ENABLE_TRACE in your project's preprocessor definitions. When this is defined trace functionality will be enabled in system_nrf52.c as seen in the screen shot below.

image description

  1. Configure ETM in your Debug Settings as in the screen shot below. More info here: http://www.keil.com/support/man/docs/jlink/jlink_tracing.htm.

image description

  1. Start the debugging session and open the Instruction Trace Window or the trace window of your choice. http://www.keil.com/support/man/docs/jlink/jLink_uvision_windows.htm.

image description

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!

#Conclusion 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.

  • Hi,

    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 !

    Quentin

  • 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.

  • Hello, just want to point out that the SWO traces, i.e.

    •Debug message: Generated by ITM, provides message output such as printf in the debugger GUI.

    seem to work with Nordic on-board debugger. I am using those just now.

  • Matts:

    image description

    That is from the SEGGER manual. Looking at it I would expect you to need to connect the SWD Lines, Trace Lines, nReset, VTref and GND. But I'm not sure, I just used the connector board I was given. Don't let the fact that the 19pin and 9pin ports were used confuse you - its because the trace lines are on the GPIOs and the SWD lines are on the Debug In port and this was the easy way to connect all the lines.

    Sven:

    Yes this is supported in the SEGGER IDE. I have been meaning to test it out. Looks like it is very easy to enable in that IDE, you could look at the documentation here and search for trace: www.segger.com/.../segger_embedded_studio_manual.pdf.