Data Trace View showing spurious values

[JBrau.3]

I have been trying to get an event viewer working based on SWV data trace. To start with, I decided to try to use the data trace viewer to plot a simple state variable that will bounce around values 1-4.

I am able to get something out of the SWV, but it seems to be garbage, or garbage enough to make the plot useless: I can't figure out if this is something wrong with my programming, the SWO interface, or the graphing. I would really like to be able to natively plot values using these hw comparators, but if the debugger isn't going to give me data accurate enough to tell what's going on, this seems useless.

I have tried so many settings, removing everything else from the trace settings, and this seems like the best I can get.

[JBrau.3]

This is what my data trace looks like, not sure if its showing up in the above post.

[Markus GIRDLAND]

This could be due to a few reasons. You could check the SWV Data Trace view and the SWV Trace log view to make sure that you're receiving correct data or if you're just getting garbage/overflows.

Also, double check that you have the correct Core Clock settings.

If you're receiving correct data but the graph still shows up like this then there might be a problem with the graph view. I can run some tests with the graph view on my end.

[JBrau.3]

Thanks for the reply. Taking a look at the log view, it seems like I get 4 most of the time, which makes sense, the fw will sit in the "sleep/wait" state which is defined as 4. Unsure if the timestamp delay is causing some issues.

It also looks like the data trace channel is sending this garbage, very occasionally:

These are my settings for this run:

If I bump the timestamp prescaler up to 4, I get fewer timestamp errors, but I still get the same garbage. I also get some spurious "Data Trace Address Offset" which seems to be correlated to the bad data.

So I guess if I'm getting this data, then the graph view is fine, but somehow those values are getting put into the ITM packets. It doesn't make sense, unless something is accessing this memory when it shouldn't, modifying the value to something random, and then immediately changing it back?

[Pavel A.]

Is your core clock indeed only 24 MHz? This number is not the oscillator frequency! It is the clock of the ARM core.

-- pa

[JBrau.3]

Pavel, thanks for your reply. Originally, I was certain that my clock and debug settings matched. Looking at my SYSCLK setup for the clock speed and matching the debug configuration to it.

However, I went back and double checked it all, starting from a cleaner state of my code. Setting up the clock to 24MHz and the debug clock to that worked this time. I must have had some stale configuration in the IOC file or debug configurations causing some issue.

Additionally, my SYSCLK speed is typically 20MHz, and I had mostly been changing it to align to a tutorial for the Data Trace, which had a 24MHz core clock. So switching back to 20MHz for both IOC and debug configurations and rebuilding resulted in the original issue again. Given that, I assumed it must have something to do with the clocking, so I tried changing the SWO clock from 2kHz to 1kHz, and I get good data again. Is a power of 2 SYSCLK necessary for these debug features to work correctly?

 

It looks like my states may be passing too quickly for the sampling to pick up all the time, but given that these are all valid values the variable can take, I think this is working as best as I can expect.

Thanks for everyone's help!

Jordan

[JBrau.3]

Ah, additionally, I was hamstringing myself. Because of the crazy values I was getting, I had a temporary variable that was being written to almost constantly:

while(1)
{
   state_temp = (real_state % 6);
   ...
}

This cause that comparator to try to send the status of the state_temp variable over and over, burdening the trace interface.

Fixing the clocking (SWO frequency to 1kHz), and doing a comparator to the "real_state" variable which is written infrequently generates a very nice graph, and much less load of the trace interface and IDE.