In several places I've read that the trace clock frequency is usually half that of the core clock frequency. One such place is the following link: https://www.segger.com/products/debug-probes/j-trace/technology/setting-up-trace/
"The trace clock speed (TRACECLK) is on most microcontrollers directly dependent on the CPU clock speed and is usually half of the CPU clock speed". In the i.MX RT 1060 data sheet, the maximum trace clock frequency is listed as "ARM_TRACE_CLK frequency of operation", and has a max value of 70 MHz. This is substantially less than 1/2 the max core frequency of 600 MHz, which would be 300 MHz. It appears the trace bus is 4 bits wide. Is the width the reason the trace clock can be 70 MHz? Even at 4 * 70 MHz = 280 MHz, that is still less than half the max clock frequency of 600 MHz. Is the amount of trace information limited in order to run at such a low trace clock frequency? Or is all of the potential information present and it is right on the edge of the bandwidth limit?
Thanks,
Greg
Hi Igor,
Thank you for the additional information, which helps. Section 7.2.2.3 says "it usually generates compressed information about the program flow", which suggests 600 MHz of core activity could potentially fit into a lower-frequency trace stream that is 4 bits wide. Maybe I'm asking the question in the wrong way and leading you in a direction that I didn't intend. I'd like to restate my question. Will a debugger using a trace probe connected to a 4-bit-wide data path be able to reconstruct every instruction when the core is running at 600 MHz? If the answer is yes, then I won't be disappointed when I purchase a trace probe and start using it. If the answer is no, what can I expect?
I'm looking for people that have used trace probes with the i.MX RT family and can tell me if they are limited in any way because of the high core frequency.
Best regards,
Greg
Hi Greg
seems this depends on trace packet size, one can look at ETM specification and estimate it:
https://static.docs.arm.com/ihi0064/d/IHI0064D_etm_v4_architecture_spec.pdf
also as this question is specific ETM (vendor of this module is arm) one can post question
on arm community
Best regards
igor
Hi Igor,
I'm unsure what you're saying exactly. Are you saying that a trace probe that can utilize a 70 MHz trace clock will capture every single instruction when the core is operating at 600 MHz? Or you're saying that the max core frequency of the Cortex-M7 would be limited to 140 MHz?
Best regards,
Greg
Hi Greg
exactly was said that max value ETM Debug trace pads is 70 MHz
according to datasheet. As described in sect.7.2.2.3 Embedded Trace Macrocell (ETM)
i.MXRT1060 Reference manual :
For more information about ETM, refer to ARM® CoreSight™ ETM-M7 Revision r0p1
Technical Reference Manual.
So relation to max core frequency of the Cortex-M7 one can find in arm documentation.
https://static.docs.arm.com/ddi0494/b/DDI0494.pdf
Best regards
igor
Hi Igor,
Thanks for the reply to my question. If it is limited in frequency, does that limit the capability to trace? If so, what are the limitations? What doesn't get recorded?
Best regards,
Greg
Hi Greg
I've found a solution for tracing the IMXRT1062 at 600MHz. I am able to use a 400MHz trace clock, which is perfect for this purpose. Initially, I tried using the Segger Jtrace, but it wasn't stable. Instead, I got successful results with uTrace from Lauterbach. I have attached a screenshot of my test for your reference.
Please note an important detail: the MCUXpresso Clock Config tool limits the Trace clock to 132MHz, and attempting to set it higher will result in an error. However, you can bypass this by manually configuring the trace clock register. For my setup, I used the following configuration, which worked perfectly:
/* Set TRACE_PODF. */
CLOCK_SetDiv(kCLOCK_TraceDiv, 0);
/* Set Trace clock source. */
CLOCK_SetMux(kCLOCK_TraceMux, 1);
Best wishes
HM
Hi Greg
except max. frequency, there are no other functional limitations.
Best regards
igor
Hi Greg
I believe you are right, seems for i.MX RT1060 data sheet the maximum trace clock frequency
is limited due to slow pad buffers logic (defined by technology) and internal delays.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------