Feature Request / Show the CPU Load of executed functions, including subfunctions

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

    • Feature Request / Show the CPU Load of executed functions, including subfunctions

      Hello,

      I'm trying to do a performance analysis on a STM32F7 processor with a J-Trace Pro Cortex M.

      As an example, I have a ProcessAdcDataHF(...) function for which I would like to know the overall CPU load and how large the portion of the executed subfunction arm_rfft_fast_f32(...) from the ARM library is.
      I like to know the average CPU load, the minimum execution time and the maximum execution time.
      During the execution of the ProcessAdcDataHF(...) function are occurring a lot of small interrupts for which I do not like to have the time added to the CPU load of the ProcessAdcDataHF(...) function.

      In the "Code Profile" window I can see the CPU load of each individual function, but excluding the subfuctions, which makes it useless for my purpose.
      In the "Timeline" window I can see the execution over time, which shows me the start time and the end time of each function, but this time also includes all the interrupts, which makes it also useless for my purpose.

      I like the Ozone software, it has some nice features, and works with only providing an .elf file. Since there is already a "Timeline" view, where you can see, how exactly the functions are called, maybe it is possible to incorporate the CPU Load into for example the "CallGraph", so that CPU Load of the whole system can be analyzed.

      Best Regards,

      Chris4711
    • Hello,

      Thank you for your inquiry.
      To implement something like this we would need to keep the complete timeline recording since start and analyze it on the go. Unfortunately such live analysis would not be viable in most cases as such trace recording would ramp up to a couple GB in size in just a couple of seconds while more data is pouring in from the target.

      What could work is to dump the data in some file and start analysis after the recording is complete. However this would only be viable for short recordings, because if you have a recording that e.g. runs a couple of ours, the analysis will typically take at least that amount of time to analyze and decompress the data which would make this feature very tedious to use.

      So as you can see with Arm tracing you very quickly come into the "big data" domain and in our experience not many of our customers are equipped to handle such data.

      But anyhow the variant where we have the data recorded and do the analysis after the recording is done is on our feature wish list, but with low priority with no fixed time schedule right now.

      Alternatively what you could look into is software tracing with e.g. SystemView:
      segger.com/products/development-tools/systemview/

      There you can measure such metrics already if you have instrumented your application.
      But this comes with the cost that it is not non-intrusive like Arm tracing.
      The time impact of a SystemView call is in the magnitude of ~1 us typically.

      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.