From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂

Package

The unit came with all the cables: two USB, Ethernet, 20 pin and 19 pin Cortex ribbon cables plus a 5V/700mA USB power supply (for the small debug board, more about this later):

The box includes the ‘Cortex-M Trace Reference Board‘, powered by a ARM Cortex-M4F (STM32F407VE). For this one there is the provided 5V USB power supply, the J-Trace itself gets power through the USB plug. The unit has both a USB and Ethernet/LAN host connection:

The reference board is actually a really cool thing: I board I can use with the tutorials and don’t have to mess up with my hardware first (more about this later).

💡 The reference board  is sold separately too, but did not find it in the Segger web shop. The trace test points are available on the board, and if more pins would be available (e.g. for a header row), that could be a cool general purpose board too.

Main features of the trace unit:

• ETM Tracing and Cortex-M debugging
• USB 2.0 (480 MBit/s) and Gigabit Ethernet interface
• ‘Unlimited’ streaming to the host
• 64 MByte on-board trace memory
• Supports all Cortex-M (M0, M0+, M1, M3, M4, M7)
• 50 MHz JTAG speed
• Can be use like a normal J-Link debugging probe

As with other Segger probes, there is Windows, Linux and Mac OS host support. I have used the J-Trace under Windows.

Debugging

The probe can be used like a normal Segger J-Link debugging probe, e.g. with the NXP Kinetis Design Studio or any IDE which supports the Segger J-Link probes. What I noticed compared to the Segger EDU or the OpenSDA implementation that it is much faster downloading :-).

Unlike the ‘normal’ Segger J-Link units, I do not need a SWD cable adapter as 20pin Cortex Debug+ETM connector (labeled “Target+Trace”):

I still could use the J-Link adapter board if needed on the ‘Target’ port (but that will be for debugging only). This makes sense if need access to the signals or want to use the 10pin debug cable instead (note that the J-Link Adapter Board is not part of the J-Trace package):

There are several status LEDs on the unit which are very helpful to solve possible oversights like target not powered. The ‘Trace’ LED is on when the units collects trace:

Debugger? Ozone!

The Eclipse based Kinetis Design Studio does not include trace capabilities. CodeWarrior does, but all my current NXP projects are running either with LPCXpresso or with the NXP Kinetis Design Studio, and CodeWarrior is kept only for legacy and maintenance projects. I saw that the Segger documentation and tutorials mention Ozone. Ozone is Segger’s own debugger which of course supports the J-Link debug probes.

In case of an ’emulated’ J-Link like the OpenSDA J-Link (or J-Link EDU) firmware a dialog pops up:

When I first saw the news about Segger providing their own debugger, I was kind of thinking: “Why yet another debugger?”. Well, after using it a for a few days I think it is a actually a good things: it is small (14 MByte download), it is very snappy and fast, and does its job very well:

The download/installation comes with a few CMSIS-SVD files, but I can download and add more SVD files (see for example “CMSIS-SVD Register Files with Eclipse MARS and EmbSysRegView“).

And with the J-Trace tutorial, I was indeed able to get the trace demo working in less than 15 minutes :-), using the reference board:

Ozone Views

Ozone features all the usual views I expect (source, memory, console/terminal, registers, disassembly, call stack) and many more:

Views can be moved around and put over each other to have a ‘tabbed’ view. Views can be moved out of the main window, such as to be placed on a separate monitor display.

The source view offers line numbers, setting breakpoint. What I really like is that I can unfold a source line and it directly shows the disassembly code:

I miss the ability to jump directly to symbols (aka ‘go to declaration/definition’), but I understand that this is more of an IDE feature.

The debugger has an easy way to attach to an already running application (this is usually a big pain in other debuggers):

The ‘Download & Reset Program’ does exactly that. There is no way in the UI to specify say a temporary breakpoint on main().

Scripting

Ozone has a nice scripting engine: It seems that pretty much everything is scriptable:

Actually the Ozone project files are kind of C files written in that scripting language: that way I can easily change the debugger:

Trace View

The instruction trace shows the executed instructions and shows it synced with the source and disassembly view:

It automatically groups the trace instructions by the functions:

Trace gets streamed to the host application (Ozone) is almost ‘unlimited’ that way, and I was able to collect trace for a long time.

Code Profile View

The Code Profile view shows source and instruction coverage based on the instruction counters:

The execution counters can be turned on in the source view:

Eclipse

While I wish that would work the same way in Eclipse, unfortunately there is no Ozone Eclipse plugin (yet?). Just imagine: getting the instruction trace and profiling information into Eclipse, that would be fabulous :-).

I’m working with Ozone in the following way: I build the project in Eclipse and have the .elf file/project configured in Ozone for debugging. When I rebuild the .elf file, Ozone automatically detects the change and reloads it:

Again, an Eclipse plugin would be the preferred solution, but the above way works well.

Summary

The J-Trace works really nice in combination with the Ozone debugger. First I thought that this Ozone debugger is not necessary. But it makes sense, plus it can be used with Eclipse or any other IDE.

I was able to get trace with Ozone, J-Trace and the Cortex-M Trace Reference board in a very short time early this Sunday morning. But I have spent the rest of the day to get trace out of my TWR-K64F120M board, so I have to come up with a follow-up article.  This is why I think Segger includes that trace reference board as a starting point: Getting trace out of the Tower board was not easy because of wrong board documentation and example code, and trace pins used for other board components. This is not the fault of Segger, but it made it clear to me why Segger provides that reference board: “it simply works”.

The follow-up article about tracing Kinetis with the J-Trace has to wait for a few days until I find time to publish it, so stay tuned. And to all the bugs out there: You have a few days more to hide, but not more! 🙂

Happy Tracing 🙂

Links

• Segger J-Trace Pro for ARM Cortes-M: https://www.segger.com/jtrace-pro-cortex-m.html
• ARM CoreSight ETM-M4 description: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0440c/DDI0440C_etm_m4_r0p1_trm.pdf
• Community discussion about ETM on Kinetis: https://community.nxp.com/thread/349983 and https://community.nxp.com/thread/300553
• ETM on Freescale Tower Boards: https://community.nxp.com/thread/349983
• Cortex-M Debug Adapters: http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf
• J-Trace and Ozone tutorial video: https://www.youtube.com/watch?v=hl7WdxnD9k0
• Segger Ozone: https://www.segger.com/ozone.html