Hi. I’m trying out the free version of Percepio viewer. I have the trace recorder integrated with the project and everything seems to be working. But in the viewer I get some strange timestamp values and also errors about time moving backwards.
I am using the Arm Cortex A9 port. I debugged a little in the code looking at the timestamp values and I can’t see any obvious problems. The timer register that it reads appears to be correct.
Capture and screenshot are attached. Is there any information in the capture that might point to the problem?
I now see that my counter reload value is 333,333, and counts down to 0 for the 1ms system tick. It makes sense that most of the events that are captured happen quickly after the system tick so that seems like why the error values are all around -320,000 to -333,333.
One thing I found I can do, is that I can get the timestamps at the OS Tick resolution (1ms in my case) if I force the timer counter value to 0. So something is misinterpreting the counter value.
I figured out that the problem was from when the timer period was read during the trace initialize the value was 0, and that was causing the problem from the first post. The timer period does get set but not until the scheduler is started.
For now I just hard coded the timer period to the value used and that it good enough for my testing now.
This is a common issue when using the OS tick timer as time source. FreeRTOS initializes the timer and reload register when the scheduler starts, so the timestamping doesn’t work before that point. Your approach seems like a sensible solution, although all events before the scheduler is started probably get a 0 timestamp. Another solution is to move the xTraceEnable call to the vApplicationDaemaonTaskStartup hook and add a call to xTraceInitialize early in the startup, before any FreeRTOS calls are made. This won’t trace the early events though, but I think the object creation during the startup (task names etc.) is still captured.
