Enable streaming trace on ChipWhispere-Lite and ChipWhisperer UFO

Hello all,

I am trying to enable the streaming trace with J-Link on ChipWhisperer-Lite and UFO. However, according to the Segger’s wiki, the J-trace interface is different from the JTag interface. The ChipWhisperer-Lite seems to have none additional pins for TRACEDATA. ChipWhisperer UFO, in the contrast, have more pins but they are unclear to which pins I should connect with J-Link. Does anyone have experience for this? Thanks in advance!


Our STM32 targets do not not have TRACEDATA pins.
If you look at the STM32 datasheet, you’ll see TRACEDATA pins but only on the larger packages – not the one we use.

Our K82F target has the TRACEDATA pins; they are broken out on J1 (see the schematic).

I see. Does this mean there is no other way to do streaming trace on these STM32 targets?

It is possible to get trace data from the SWD pin, and we actually have a notebook that shows you how.

SWD is a serial interface so its bandwidth is much lower than the parallel trace interface, so I don’t know how useful it would be for “streaming trace”. You’ll have to look to the Arm / Segger side for that.

Thanks for the notebook :D.
But SWD seems to do periodic sampling only. Did I miss anything?

Our examples shows periodic sampling and PC match events, but that’s just an example. AFAIK there is no limitation to which trace data can be output on SWD; it’s only the bandwidth that’s limited.

See e.g. Using Single Wire Output when parallel trace isn’t available – Orbcode

Hi, sorry for the late response since I was away.

I read the article but I actually do not understand what the code is transferred for. However, I found PC match mechanism can work in my case. Since I don’t have Husky and other CW hardware tracing devices, are there other ways to do PC match mechanism from scratch? Thank you!

Note: I found DWT comparator functions can do things for instruction address matching. But do they create additional instructions on the main program we want to measure power trace from?

The whole point about Arm trace is that it doesn’t alter the execution of your program whatsoever. This is what’s so cool about it. Think of it as a separate piece of hardware running alongside the processor and observing it, but not disturbing it in any way.

If you want to record trace data with your J-Link, go right ahead!

If you want to trigger power trace captures (or glitching) from trace data, then AFAIK the only way to do that is with our TraceWhisperer.

Thanks for your response! What I can achieve right now is periodic sampling which won’t disrupt the normal execution at all. But the disadvantage is that it only has maximum 128 cycles per sample (ST-Link V2 cannot take 64 cycles, no idea why). In other words, I will have to repeat the same procedure for multiple times to achieve enough samples I want. That’s why I am wondering whether they have better approach for that (e.g. stream tracing).

Speaking of DWT comparator, it can cause interrupts when an MCU fetches selected instruction addresses. However, the number of addresses are limited and the interrupts will cause the program to halt as well. What I hope is that the debugger can get a signal when the first instruction of every basic block is fetched and the execution of the MCU shall not be disrupted either. Do you have any idea how to achieve this?

Right, I misspoke slightly in my previous post: I had forgotten that some trace events can cause interrupts.

However it is possible to use the DWT comparator to get trace events when the PC reaches a specific address, without firing an interrupt. We show how in that TraceWhisperer notebook: look for the set_isync_matches(), which is defined here: https://github.com/newaetech/chipwhisperer/blob/develop/software/chipwhisperer/capture/trace/TraceWhisperer.py#L1045

The bad news is that you can only set up two PC addresses this way.

Keep in mind that our example only scratches the surface of what you can do with trace. As you can probably tell from Arm’s documentation, there’s a seemingly infinite number of things trace can do. The orbcode people have some great resources to learn more; most of it’s written from the perspective of their tools, but I think it’s still hugely helpful towards understanding trace better: Orbuculum – Orbcode

They also have a discord (link on their github), and while it’s meant for users of their tools, you’ll likely find people there with deep knowledge of trace.