[SOLVED] Trace timeline only goes to 10M instructions?

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

  • [SOLVED] Trace timeline only goes to 10M instructions?

    I am using a J-Trace Pro with a J-Trace Pro, with Ozone.
    When I look at the timeline view, it looks like the history only goes back to 10M instructions. On a 100MHz cpu, that's not much time!

    Is this a hard limitation? My understanding was that streaming trace should give me "unlimited" history, or as much as my PC memory/hard drive can store.

    Then a similar question is whether or not there is a history horizon on what is going into "Code Profile" output, particularly the "Load" column.
    I am dealing with a closed source library, and I am trying to do some measurements, e.g. is it slow because it is doing heavy compute, or slow because of timed flow control internally.
  • Hello,

    Thank you for your inquiry.
    The 10M instructions in Ozone timeline is currently a hard limit which will be lifted in future versions.
    Unlimited is currently true for all code profiling, coverage, and instruction counter information.
    The timeline had to be capped due to careful resource management with that much trace data on the host PC.
    This is however not necessarily needed anymore and will be improved.

    Then a similar question is whether or not there is a history horizon on what is going into "Code Profile" output, particularly the "Load" column.

    The load column shows the CPU load of each task/function relative to each other in regards of how many instructions of the total instruction have been spend in that function.

    Best regards,
    Nino
    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.
  • OK, great.
    On the topic of resource management, I usually have to quit Ozone if I leave a program running with Trace on for more than an hour or so.
    And Activity Monitor reports Ozone using > 100GB memory (only have 16GB physical memory). Screenshot attached.
    Images
    • Screen Shot 2018-04-20 at 1.48.53 PM.png

      242.43 kB, 1,372×888, viewed 296 times
  • Hello,

    the high memory usage does not seem normal.
    Could you provide us with a reproduction scenario?
    I suspect you are using macOS?
    If yes which version?
    What target device are you debugging?
    Is it an eval board or custom hardware?
    Could you provide us with the elf file you are debugging?

    Best regards,
    Nino
    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.
  • Ozone is 2.56g
    OSX platform, version 10.13.4
    Target is STM32F412VGT6
    Adapter is J-Trace Pro
    Custom hardware (since NO boards make ETM available)
    ELF file I can't provide. I'll try and generate a MWE some time soon. It is based on the Cypress WICED SDK.
    ThreadX is running in the program, and I have previously posted about Ozone not correctly unwinding the context switches, so that may possibly be related.

    This machine has 16GB RAM, and chronically low HD free, ~10-12 GB, so I am not sure how it gets to this situation. The 100GB reading could be spurious, and a result of exhausting all the HD space that is available for buffering, if that is how Ozone is presently set up.
  • Another follow-up, given the hard limit:
    Is there ANY solution to get a longer instruction trace out presently? Even a command line logger that you might be able to share? Or something with GDB?

    I have a situation where a vendor has supplied a closed-source library with a bug that they claim they are working to fix. I have a reproducible fault case here, and I would like to see what execution looks like as it heads into this fault case. Given that, there may be workarounds I can outside the library, based on the path I see.

    Unfortunately, right before the failure, there is a very long crypto sequence which takes up all 10M instructions, so I can't really figure out what has happened post-mortem. Even a call history would be quite useful.
    (and no SystemView for ThreadX...)

    SEGGER - Nino wrote:

    The 10M instructions in Ozone timeline is currently a hard limit which will be lifted in future versions.
  • Hello,

    Is there ANY solution to get a longer instruction trace out presently? Even a command line logger that you might be able to share? Or something with GDB?

    Currently not. We are working on a J-Trace SDK at the moment so you will be able to configure where to dump the trace data for later analysis.
    Unfortunately this feature is not public yet but will follow in the next couple of weeks.

    Regarding the Ozone memory leak on MacOS. We were able to reproduce this behaviour (with a much lower leakage rate with our projects) and are investigating it further. A fix should be available soon.

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