[SOLVED] idle task with unrealistic high CPU load

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

  • [SOLVED] idle task with unrealistic high CPU load

    Dear all,

    there was a similar question a while ago that was reporting an unrealistic high CPU load for the idle task (see below). I see the same in my application. I'm using SystemView 3.12. I have the suspicious that is related to the relativ short run-time of all other tasks I have. Most of them are just above 0%. So that might cause calculation and rounding problems. But this is just a guess. Attached you find a screenshot that is showing the behaviour. It is taken from a FreeRTOS 10.0 application running on a Cortex M7 core.

    icabrera wrote:

    Hello.

    Why in some cases, the total CPU Load is more than 100% ?

    In a project I am working (10 tasks) total CPU Load is 113.33% (97.47% of Idle).

    The same project but deactivating 5 tasks total CPU Load is 3562419491.95% (which is obviously incorrect)

    Also I have seen a very big number in one of your examples (FS_DeviceActivity.SVDat) where Main Task has a total CPU Load of 1713307895155.56%

    I am using SystemView v3.10.


    Am I forgetting to add something else to my project?


    Thanks.


    Maybe someone have an idea how to get rid of this small problem. I marked the idle task CPU load.

    Best Regards
    Markus
    Images

    • idleCPULoad.PNG

      136.26 kB, 1,585×1,100, viewed 760 times

  • Hi Markus,

    Thank you for your inquiry.
    I assume your instrumentation calls SEGGER_SYSVIEW_OnIdle() as expected, correct?
    In that case this might be related to a bug in regards to CPU load display when unexpected events are recorded.
    This will be fixed in the next SystemView version.
    Could you provide a sample recording for verification to make sure this is not an unrelated issue?
    You can save the recording via File->Save Data.

    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.

  • Dear Nino,

    thanks for taking care.
    I just updated to FreeRTOS 10.3.1 and to SystemView 3.12. With this the problem disappeared. For me hard to say where the root cause was related. So I consider the case as closed.
    Anyway, I was able to apply the patch that is included in the SystemView installation with a little bit of searching up and down the files. It looks like the FreeRTOS people have recently rearranged things quite a bit.
    Just one thing that might needs consideration in the future. The prvNotifyQueueSetContainer() function has been changed by the FreeRTOS people. It doesn't contain anymore the xCopyPosition parameter or local variable for it. So the traceQUEUE_SEND() call fails. Because I'm not using QueueSets it's fine for me. I think in one of the next releases of SystemView something like a traceQUEUESETS_SEND() macro should be added that deals with that.

    Best Regards
    Markus

  • Hi Markus,
    Good to hear that you are up and running again.

    markuskrug wrote:

    The prvNotifyQueueSetContainer() function has been changed by the FreeRTOS people.
    Thank you for making this known to us.
    I passed this on internally.

    We will close this thread now.

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