Hi FreeRTOSler,
i want to ask if the Legacy Trace Utility is still working in the new FreeRTOS versions.

in this website: http://www.freertos.org/a00086.html
there is an example where 10 milliseconds were captured and presented in timing diagram.
how can i get the same information about my application?

Regards.

Hello,
the functionality behind configUSE_TRACE_FACILITY is still working and I'm using it actively. But I'm using the textual output shown on http://www.freertos.org/a00086.html, not the graphical diagram variant: this is depreciated and has been removed from FreeRTOS V7.1.0.
It has been replaced with the more powerful and versatile Trace Hooks. This is what I'm using in combination with the Percepio Trace utility, see http://mcuoneclipse.wordpress.com/2012/03/23/tracing-with-freertostrace-from-percepio/

Hope this helps,
Erich

Hi Eric,
thank you for your reply.

i tried to use Percepio Trace utility, but it is still not working. so maybe i will ask again later.

Best Regards.

Hi again,
i have some questions about the Percepio Trace utility.
i hope that is the right forum to write it.

the RAM dump file that must be recorded must contain only the EVENT_BUFFER? or can i record the whole RAM and the utility will recognize, in whic part of the RAM the EVENT_BUFFER is exsiting?

Regards

Hello,
It is ok to dump the whole RAM, as Percepio is using a signature to detect where the trace buffer starts.
But usually I just dump only the 'RecorderData' structure because of performance (especially if RAM is rather large).

Hope this helps,
Erich

Hi,
it helps, but how can i know from where to where the dump is existing?

thank you ver much for your efforts.

i ment, how can i know from where to where in the RAM the "RecorderData" is existing?

Hi,
that depends on the tools and debugger you are using. If you dump the data from your application, then the application knows the address (&RecorderData) and the size (sizeof()).
If you use a debugger like CodeWarrior in Eclipse, then I do it with a TCL script which calculates the address and size of the RecorderData:

set start_addr [evaluate &RecorderData]
set end_addr [evaluate ((char*)&RecorderData) + sizeof(RecorderData) - 1]
save -b $start_addr..$end_addr c:\\tmp\\myTrace.dump -o

(see http://mcuoneclipse.wordpress.com/2012/03/23/tracing-with-freertostrace-from-percepio/)

Hope this helps,
Erich

Hi Erich,

thank you a lot for your detailed answer. it helped me solving the problem.
but now the utility cant read the RAM dump file.
i dont know what is wrong now, i saved the whole RAM and opened it with utility, but it showed me that it is in processing and nothing works at end.

Hello,
this sounds like something you should report to Percepio. As mentioned above, Percepio is using a signature (special byte pattern) to detect the starting of the trace buffer in a full memory dump. If your memory has by chance such a pattern, it might wrongly assume that this is the trace buffer, causing maybe what you are seeing. So if you can, reduce the memory size / area you dump, or just dump the trace buffer. And I suggest that you send your memory dump to Percepio in any case: the reader should not stall (at least this is what I read from what you say).

Hope this helps,
Erich

Hi Erich,
>> "If your memory has by chance such a pattern, it might wrongly assume that this is the trace buffer"
actually my memory must have such a pattern, because the trace buffer is a part of it. or do u mean, if my memory has a second one of these pattern by chance.

Yes, I meant that your target memory might have the same pattern as the pattern/signature of the Percepio Trace Buffer.

Erich

Hi
If you get a trace data file that fails to load in FreeRTOS+Trace, please send it to support@percepio.com. We try to analyse such cases asap, but please allow us a few days to reply.

Erich, thanks for helping out. I was not aware of this thread until now.

Regards
Johan Kraft
Percepio AB

Hi
The pattern problem was (probably) solved in v2.2.3, for the record. However, recording of high-priority ISRs (i.e., above FreeRTOS IRQ levels) may corrupt the trace, depending on FreeRTOS port and settings (at least on Cortex M3). We are working on a fix for this.
The reason/problem is that the FreeRTOS macro for disabling intrerrupts, which may leave high-priority ISRs active during critical sections. This is a good optimization from an RTOS point-of-view, but a bit problematic for us... We will probably need to introduce independent event buffers per ISR.

Regards
Johan Kraft
Percepio AB

Hallo Johan and Erich,
thank you a lot for your postings and helping me to discover the problem.
i will send an email to the support, and i hope you can find out, what is the problem in this case.

Regards,
Mohammad