[ABANDONED] Ozone hangs with timeline open when sample rate is set to Max

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

  • [ABANDONED] Ozone hangs with timeline open when sample rate is set to Max

    Hello all!

    On Windows 11, with a Segger Ultra+ debugger, we opened a timeline and sampled 3 variables. When we set the sample rate to max, Ozone hangs for about a minute and becomes unresponsive. We click pause, ozone continues to hang, eventually services the click, and returns to normal function.

    This happened on multiple computers.

    It seems that this behavior is triggered by how the timeline variables are referenced. If we select the desired variables via a global reference, the timeline functions as normal. However, when we tried to reference the vars through a singleton interface, the timeline became unresponsive. We suspect the timeline was re-parsing the singleton-reference every sample, causing the delay.

    ex.
    singleton::instance.struct.var (hangs)
    vs.
    pre-stored-pointer-to-instance.struct.var (functions as expected)


    TY in advance!

  • Hi grb212,
    Do you use the latest version of Ozone? Are you able to reproduce the issue on Ozone V3.36? If so, could you please provide a reproducer on an eval board? We'd require the ELF file, the Ozone project, and detailed instructions on what to do to reproduce the issue on that very board.
    Best regards
    -- AlexD
    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.

  • I made similar observations (win10, ozone 3.36, j-link ultra+ v5.1). quick example:
    I have these variables:

    C Source Code

    1. // global struct
    2. typedef struct {
    3. uint32_t dbga1;
    4. uint32_t dbga2;
    5. uint32_t dbga3;
    6. } GD_t;
    7. volatile GD_t D7;
    9. // global variable
    10. volatile uint32_t dbgb1;
    11. volatile uint32_t dbgb2;
    12. volatile uint32_t dbgb3;
    14. // static variable
    15. void foo(void) {
    16. static volatile uint32_t dbgc1;
    17. static volatile uint32_t dbgc2;
    18. static volatile uint32_t dbgc3;
    19. }
    Display All
    I want to sample D7.dbga[1-3] or dbgb[1-3] or dbgc[1-3]
    All variables are in the same memory (DTCM of a STM32H745 in this case)
    Sampling with max frequency results in requests send every ~20us on the SWD lines running at 25MHz.

    observations:

    sampling D7.dbga[1-3]
    =>GUI very laggy, many sample points missing



    sampling dbgb[1-3]
    =>GUI laggy, some sample points missing

    (but one time this also ran smoothly)


    sampling dbgc[1-3]
    => ok



    sampling <artificial>::dbgb[1-3] (result of "graph" in context menu of GlobalData pane)
    =>GUI very laggy, many sample points missing



    sampling (<artificial>::D7).dbga[1-3] (result of "graph" in context menu of GlobalData pane)
    =>GUI very very laggy, many sample points missing



    sampling addresses directly
    =>GUI very laggy, many sample points missing



    btw.: changing the variables that are being sampled, while sampling on max, often results in breaking the sampling all together and I have to powercycle the probe and restart ozone.





  • Hi fraengers,
    as stated before, we need to be able to reproduce the issue locally. Could you please provide a reproducer, as described in my previous post?
    Best regards
    -- AlexD
    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.

  • New

    Hi fraengers,

    We have successfully reproduced the issue. At first glance this seems like it could simply be that a part of the chain is overloaded. This could be some buffer, the connection itself or even the host system.
    We will of course check whether we can improve this, but at this point we cannot make any promises.

    As a workaround lowering the sampling frequency and/or the J-Link connection speed reduces the load, stabilizing the data sampling.

    Best regards,
    SebastianB
    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.