Hello,

We are encountering the error message below when fetching traces, not all the time but only a tiny fraction of the time:
LTRACE (Time since start: 1.172 679, Thread=ETM3): Unknown trace data packet detected (Offset = 0x102C3, Data = 0x00)
Parts of it change every time, like the time, thread ETM number, and offset.

We use the J-Link SDK, and in our use case we fetch traces from the unit around ten times a minute using the STRACE API, specifically the --removed by moderator as discussing J-Link SDK API publicy is a license violation-- function of the J-Link DLL, which is the call that sometimes fails.
In our use, the unit gets reset regularly and tracing is started and stopped just as often.
The trace data we get is valid when the call succeeds. When we run tracing continuously, we usually get the error within 5 to 20 minutes.

We have the following setup:
Probe: J-Trace PRO V2 Cortex-M compiled Nov 12 2020, Hardware version V2.00 (see additional screenshot attached)
DLL version: V6.89b, compiled Dec 3 2020
Board: ADI ADuCM362, Cortex-M3

We are in the process of setting up a scope to look at the signal quality and timings, but because it works a large portion of the time, we think it could be difficult to identify an issue there.

Is there something we could be doing wrong, and what should be our next step to solve this issue?

Thank you,
Johan

Thank you for the response, I have tried adjusting the sampling delay (in the range 0-10000), and while it seemed to help (5000ps gave - I think - fewer errors than 0ps), the issue still happens with some regularity.

We also had a look at the trace signals with a scope, and it looked ok on each trace pin, and seemed to be well synchronized with the trace clock - see the attached pictures (sorry for their poor quality and labelling). We are going to look harder into this though.

I also noticed that the trace frequency (as returned by the function that starts the tracing) seems to vary a lot: I've seen it be 8Mhz, 500kHz and 490kHz. Our core runs at 16Mhz, so from the wiki page you linked I would have expected it to be 8Mhz every time. Do you know why it would change this way, and if it could be an issue?

Last observation, when we get the error and press OK, the traces we receive actually look good - none missing, and their data makes sense.
I have tried enabling Batch Mode, but it doesn't seem to stop the dialog box from appearing - is there any way around this blocking error box?

Thank you,
Johan