[SOLVED] STM32H7 ETM Trace

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

  • [SOLVED] STM32H7 ETM Trace

    Hello!

    I have a few questions about using ETM trace on the STM32H743ZI.

    I'm using Ozone v2.60g with a J-Trace PRO Cortex V2.0 connected over USB 3.

    It took me several hours to get the ETM trace working at all.
    After a lot of trial and error, I found the "ST_STM32H743_Traceconfig.pex" file in a .zip File linked on wiki.segger.com/Tracing_on_ST_…H7_Trace_Reference_Board))


    1) What does the "pex" file do?

    I didn't find this documented anywhere in the Ozone or J-Trace manual.

    Can I have the source code for the file?

    Will this be integrated in a future Ozone release?
    (STM32F4 worked out-of-the box as expected, will this be possible for H7, too?)


    1b) What is the license? Can I include and distribute it in my project?


    2) My application needs to run at 400 MHz core clock.
    Will I be able to trace at full speed?


    3) What is the maximum trace speed?

    According to wiki.segger.com/Tracing_on_ST_STM32H743, the trace clock can be set to "400/6 MHz".

    Where can I make this setting in Ozone?

    Or is this hardcoded in the pex File?


    4) What are the implications of using a Trace clock < Core clock?

    Will the CPU stall while waiting for the ETM?
    Will performance analysis and code coverage work?


    5) What are the layout guidelines for maximum ETM speed?

    Length matching and short-as-possible is obvious.
    Do I need series resistors?


    6) As I understand, the STM32H7 SEGGER demo board only achieves 133 MHz ETM clock?

    Is this a limit of the JTrace, the STM32H7 or the Board layout?


    It would be nice if these points could be addressed more clearly in the documentation.

    best regards,
    Thomas Kindler

    The post was edited 3 times, last by thomask77 ().

  • Hello Thomas,

    Thank you for your inquiry.

    thomask77 wrote:

    It took me several hours to get the ETM trace working at all.
    Did opening the example project in Ozone and get in running take hours or the search for the project? Because our projects are designed to run out-of-the-box on the examples evalboard hardware and it should only take 1-2 minutes to have trace running even for inexperienced Ozone users.


    thomask77 wrote:

    1) What does the "pex" file do?
    As written in the Wiki articles it is a compiled version of a JLinkScript which takes care of the device specific trace init e.g. init of trace pins, enabling debug clock domains etc.


    thomask77 wrote:

    Can I have the source code for the file?
    Only in exceptional cases. Could you explain why you need the source? Was trace not working with the pex file?

    thomask77 wrote:

    Will this be integrated in a future Ozone release?
    (STM32F4 worked out-of-the box as expected, will this be possible for H7, too?)
    This is not coupled with Ozone releases but with J-Link software. Due to the more complex nature of the STM32H7 core it will not be implemented to work out-of-the-box without a JLinkScript.


    thomask77 wrote:

    1b) What is the license? Can I include and distribute it in my project?
    The .pex file can be distributed in your projects.


    thomask77 wrote:

    2) My application needs to run at 400 MHz core clock.
    Will I be able to trace at full speed?
    The pins that the STM32H7 uses for tracing are specified for maximum 133 MHz. However even under lab conditions we could get stable trace up until ~118 MHz trace clock. Higher than that and the STM32H7 could not fulfil the trace signal specifications anymore and trace got unstable. For this reason are examples are capped at 100 MHz even though CPU is running on 400 Mhz. The iMXRT does a much better job here and can reach the advertised max speed of 132 MHz on its trace pins.
    The following blog article should give you a better insight on trace and clocks: blog.segger.com/current-state-of-the-trace-market/

    thomask77 wrote:

    According to wiki.segger.com/Tracing_on_ST_STM32H743, the trace clock can be set to "400/6 MHz".

    Where can I make this setting in Ozone?

    Or is this hardcoded in the pex File?
    This is done in the PLL init of the example project. You can use Embedded Studio to change these values and rebuild the project.

    thomask77 wrote:

    4) What are the implications of using a Trace clock < Core clock?

    Will the CPU stall while waiting for the ETM?
    Will performance analysis and code coverage work?
    The CPU will not wait. Worst case it comes to an overflow and parts of the trace stream is gone.
    To be able to trace a 400 MHz CPU without overflows from target to PC with 4-bit trace the trace clock should be 200 MHz. But there are no target devices on the market supporting such high speeds so ST (and other vendors in similar situations) decided to trade off guaranteed trace stability for cheaper pin driver implementations (and cheaper board designs for customers as HF signal matching is very expensive and complex).

    But for most use cases such overflows will not happen. Only if your application is very complex with e.g. many branches taken in a short amount of time an overflow can appear.
    Ozone will notify you if such an issue happens.


    thomask77 wrote:

    5) What are the layout guidelines for maximum ETM speed?

    Length matching and short-as-possible is obvious.
    Do I need series resistors?
    Termination series resistors can help. On J-Trace PRO side the interface is matched to 50 Ohms as closely as possible. So the better you are able to match your trace lanes from the CPU to J-Trace PRO to 50 Ohms the better the signal quality.


    thomask77 wrote:

    6) As I understand, the STM32H7 SEGGER demo board only achieves 133 MHz ETM clock?

    Is this a limit of the JTrace, the STM32H7 or the Board layout?
    It is a limitation by the STM32H7. As written before we reached only 118 MHz without spending to much time with the setup, ST advertises 133 MHz.
    If you fine tune the sampling delays of the J-Trace PRO accordingly 133 MHz should be reachable but the effort is unfortunately higher than usual as the pin drivers are not equally strong across all trace signals on the STM32H7 over 120 MHz.
    More information about trace setup and troubleshooting can be found here: segger.com/products/debug-prob…hnology/setting-up-trace/

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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 contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/
  • New

    Thanks for your quick answer!

    SEGGER - Nino wrote:

    Did opening the example project in Ozone and get in running take hours or the search for the project? Because our projects are designed to run out-of-the-box on the examples evalboard hardware and it should only take 1-2 minutes to have trace running even for inexperienced Ozone users.

    The problem was the unspecific error message in Ozone.

    I do my tests on a Nucleo H7 board, where I bent up the 5 trace pins, glued a 20 pin header on top of the CPU, and wired it up under a microscope.
    So I suspected a faulty connection first, before searching the Segger Wiki and finally finding the .pex file.

    After finding the Wiki page, everything went smoothly.

    Perhaps Ozone could provide a better help text, when a H7 is selected and the trace clock is missing.



    > According to wiki.segger.com/Tracing_on_ST_STM32H743, the trace clock can be set to "400/6 MHz".

    >> This is done in the PLL init of the example project. You can use Embedded Studio to change these values and rebuild the project.


    Can you point me to the exact line?

    As I understand, the PLL initialization is done in Setup/system_stm32h7xx.c, but I don't know which register to change.


    Thanks for your great support,
    Thomas
  • New

    Hello,

    thomask77 wrote:

    Can you point me to the exact line?

    As I understand, the PLL initialization is done in Setup/system_stm32h7xx.c, but I don't know which register to change.
    Our custom PLL init starts in the system:stm32h7xx.c in line 268.
    To change the PLL you need to adjust the multipliers/dividers. More information can be found in the STM32H7 manual.
    To get a visual representation on how the clocks are connected inside STM32H7 ST's software CubeMX can be used for this task.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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 contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/
  • New

    SEGGER - Nino wrote:

    Our custom PLL init starts in the system:stm32h7xx.c in line 268.
    To change the PLL you need to adjust the multipliers/dividers. More information can be found in the STM32H7 manual.
    To get a visual representation on how the clocks are connected inside STM32H7 ST's software CubeMX can be used for this task.

    Hmm, ok..

    The STM32H7 reference manual RM0433, Rev 5 says on page 3002:

    "TRACECLK is the trace port output clock. It is a gated version of the system clock
    (CK_SYS), except when the PLL1 is the source for the system clock. In this case,
    TRACECLK is derived directly from the PLL1 VCO output, divided by three. This is required
    in order to support the high data throughput on the trace port when the processor operates
    at its maximum frequency."

    If the comments in your file are correct, the VCO should run at 25e6 / 5 * 160 = 800 MHz.

    That would mean TRACECLK = 800/3 = 266 MHz, i.e. 133 MHz for the DDR Trace pin.


    The manual and CubeMX don't mention any way to change the divide-by-three ratio.


    So how do you achieve 66 MHz at the trace pin?
  • New

    Hello,

    The manual is a bit moot at that point you cited.
    The clock tree in the manual is accurate though so you can orient on that.
    In register PLL1DIVR the DIVR1 divides down the trace clock. In the 400 MHz eval sample it shifts 5 << 24 to achieve a /6 divider, default is /2 at that point.
    So you got 25 MHz(HSE)/5*160/6 = pll1_r_ck
    This reaches TPIU and is 133 MHz. In DDR fashion this outputs with 66 MHz.
    You can measure the trace clock in the J-Trace PRO web interface or in the J-Link Control panel:
    segger.com/products/debug-prob…hnology/setting-up-trace/

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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 contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/
  • New

    Hello,

    Great to hear that you are up and running again.
    This thread will be closed now.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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 contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/