Hi there,
I am the author of the open source Orbuculum tools for SWO data parsing on CORTEX-M targets. I am currently expanding those tools by implementing 1, 2 & 4-bit parallel TRACEDATA capture from CORTEX-M3/M4 CPUs using a small FPGA connected to the TRACE port running in continuous mode. There is plenty of documentation about parsing the data once it's reached the host machine but very little about the precise details of the format of the data bits out of the port.
By trial and error I think I am now collecting these DDR data correctly but I want to verify/validate what I have done. I am not certain of the exact detail of the re-sync (7F FF FF FF) and pacing (7F FF) messages, nor for the potential for bit-shifting of data in relation to the port (e.g. is b0 always on TRACEDATA0...from experimentation it would appear to have the potential to be shifted an arbitrary number of bits?). Is there any documentation or, even better, Verilog examples, of collecting the data from this port? I haven't found anything so far, but there's a _lot_ of documentation in the world of Arm, so I could easily have missed something.
Thanks in advance
DAVE
Hi Dave,
Please download CoreSight Architecture Specification v2.0 (there is a 3.0 in developer.arm.com but Cortex-M3/M4 is based on v2.0).
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0029d/index.html
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0029d/IHI0029D_coresight_architecture_spec_v2_0.pdf
Section D4 trace formatter is likely to be the information you needed.
regards,
Joseph
Hi Joseph,
Thanks for the reply...it was starting to feel a bit tumbleweed-y around here!
I am aware of that doc, and indeed Orbuculum already decodes TPIU frames over both SWO and parallel trace using the info in it, but unfortunately it doesn't tell me how the data are presented at the TRACEDATA pins. From experimentation I have observed that it is only shifted by the number of bits in the port (which, I guess, isn't such a surprise given how a DDR stream is generally created) but I would like to find that information written down somewhere to be certain that artbitary shifts aren't possible.
To provide a little more information, assuming an eight bit byte with bits 76543210 is being presented to a four bit port with pins DCBA then I have observed that bits 3210 can first appear on the high or low edge of TRACECLK, aligned to the widh of the port (i.e. D<--3, C <--2, B<--1, A<--0 on _either_ edge) but I have never observed D<--5, C<--4, B<--3, A<--2, for example. Similarly, for a two bit port, the alignment always seems to be B<--1 and A<--0 but, again, starting on either TRACECLK edge....for completeness, A<--0 is a given for a one bit port of course!
I am just trying to verify that it is indeed the case and that this behaviour is correct and that the trace output can never be shifted relative to the width of the port, 'cos that let's me remove a fair amount of logic related to finding the sync pattern - I don't need to be searching for bit shifts that can never occur!
Regards
I see. I will check internally to see if one of the engineers will able to provide more information.
View all questions in Embedded forum