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).
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.
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.
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?
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.