[SOLVED] Trace timeline accuracy

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

  • [SOLVED] Trace timeline accuracy

    Hi!

    I am using Ozone 3.10b and a STM32H743 @ 480MHz.

    1)

    I've set up ETF trace according to wiki.segger.com/STM32H7#Tracing_on_ST_STM32H743
    In the trace settings dialog, I set the source to Trace Buffer, and CPU Frequency to 480000000.

    When I do a for()-loop based delay of 4.54 microseconds (measured with an Oscilloscope), the timeline shows this as only 2 us.

    When I hover over the delay function, it says "991 Instructions executed, 2064 ns".

    2)

    When I repeat the same test with my J-Trace and 4-Bit parallel trace, the timeline says "991 Instructions executed, 7312 ns" -- which is also wrong, and does not match the scope measurements.

    What is the expected accuracy of the time measurements?

    Is time measurement possible in ETF mode at all?
    If not, I think the timeline should show instruction count on the X-Axis instead of time in ETF mode.

    best regards,
    Thomas
  • Hello Thomas,

    Thank you for your inquiry.
    1: That is expected as with 3.10 the timeline was joined with the data graph and power graph which both have their own accurate timebase.
    Now with tracing via buffer there is no timestamp information available. So we chose the tradeoff here that a user can set the CPU clock in the trace settings and Ozone then approximates that each instruction is 1 cycle. This is of course rarely the case and the timeline may appear warped.
    In your sample the average instructions per cycle is 0.44. So if you multiply your cpu clock that you set in trace settings with that values you should get a more accurate reading.
    That clock value is only used for timeline calculation in Ozone so you can do no harm to your target if you worry about this

    2: The accuracy here is usually in the single digit ns area. You can test this with the H7 tutorial project:
    wiki.segger.com/images/e/e2/ST…race_Tutorial_Project.zip

    Set the CPU clock to 64 MHz in trace settings and set a breakpoint at HPTask on OS_TASK_Delay(50); and let the application run to this value twice.

    The application is now delayed for 50 ms between two LED toggles (it does not matter if you use the same LED pins here as we are simply checking if the delay function does delay for 50 ms as set).

    If you check the timeline now you should see a delay of exactly 50 ms.


    Can you confirm this with the tutorial sample?


    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi!

    I haven't checked on 2) yet.

    But regarding ETF-Trace:



    Does that mean, that the Timestamps checkbox does not work for ETF?

    Then I think that the combined Data sampling/Instruction trace window is a little bit misleading..
    I was confused for a few hours, until I connected a scope and noticed the bogus time measurements.

    If it's not on the same timeline, data samples and trace really should not be shown to be correlated.
  • Hello,

    You are right, good catch. The Timestamps checkbox should not be there and has no functionality for tracing via trace buffer.
    This will be removed for the next Ozone release.


    thomask77 wrote:

    If it's not on the same timeline, data samples and trace really should not be shown to be correlated.
    We had to find a compromise here to be able to show all graphs in one window. So this is the compromise we decided on. We will check if this can be documented better to avoid confusion.

    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.