ETM trace maximum data rate on STM32U575

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • ETM trace maximum data rate on STM32U575

    Hello everyone,


    We are having trouble getting tracing to work with our target at full clock speed and would like to understand why, we have an application running on STM32U575 @ 160MHz CPU clock, we also connected the J-Tracer to it using a connector glued next to the uC and short wires (~10mm) to PE2 ... PE6 (pins 1 to 5 on the LQFP100), the GPIO pins are all configured (using a JLinkScript) as AF and at maximum speed, and what we understood from the documentation (Arm trace technical specification - SEGGER Wiki) the trace clock and trace data operate at half the CPU speed, I checked the ST datasheet and the GPIOs we are using should be good up to at least 100MHz, so in theory the trace should be possible with the CPU running at 160MHz and outputting trace data @ 80MHz, or?


    - I have tested with the CPU at 160MHz and 2 trace data pins instead of 4, and it works, but the trace buffer overflows every time, as only 2 data lines are too slow for the amount of information.

    - I also tested with the CPU at 80MHz and everything works as expected, with trace using all 4 data lines working without problems.



    First I would like to confirm that the HW should support this and then, if so, I will need to find out why it is not working, perhaps checking the delays with a fast enough oscilloscope and trying to optimise the distances and parasitic capacitance, any help or tips will be appreciated



    Thank you

    Gustavo Cardoso

  • Hello Gustavo,

    Could you provide the J-Trace S/N for reference?

    We can confirm that the J-Trace hardware supports 80Mhz - the trace reference board you receive with the probe btw. runs with 84MHz trace clock.
    So it should possible to run the CPU with 160MHz and 80MHz trace output from HW perspective.

    At such trace speed, clear recommendation would be designing in a trace connector on-board to avoid signal issues.

    Besides checking the delays and signal quality, you could check

    1) Are there any connections/devices connected to the GPIOs on board that might affect signal quality?
    You might also double-check our board design recommendations:
    wiki.segger.com/Trace_board_design_recommendations

    2) Try to adjust the sampling delay as described here
    Following article will guide you through the process:
    wiki.segger.com/Adjusting_trac…eshooting#Troubleshooting

    If that is done, you are back to 3), checking delays and signal quality.

    Best regards,
    Thomas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Thomas,

    Sure, SN: 752000737

    Thanks for confirming that, hardware-wise, it is within the operating ranges, regarding your points:

    1. no other signals or traces are connected to the trace data pins, although our connection is somewhat inadequate at the moment, we plan to include a proper connection on the next board revision.

    2. I followed this adjustment guide once already, but for us it was somewhat a guesswork as our connection gets bad when we jump from 2 to 4 data lines, so we must try to tune the timing for 2 lines at the same time, which is quite hard without knowing what is happening.

    I guess I will try to get it to work once more by adjusting the delays, and, if I don't succeed, we will probably only try again when we get a new PCB revision with the connector included.