[SOLVED] Software Breakpoints with FreeRTOS Tickless Idle

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

  • [SOLVED] Software Breakpoints with FreeRTOS Tickless Idle

    After enabling Tickless Idle on a NXP Kinetis M0, we are now seeing asserts from FreeRTOS when we set a breakpoint (it doesn't even have to hit it).If we don't set any breakpoints, it doesn't assert.

    The assert is in FreeRTOS Task.c:

    Source Code

    1. configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );
    It appears as if xTickCount is still moving during idle. Is there something with setting a breakpoint that changes the sleep/power save functionality related to timers?

    Example:

    Source Code

    1. print xTickCount + xTicksToJump
    2. $2 = 305271
    3. print xTicksToJump
    4. $3 = 57
    5. print xNextTaskUnblockTime
    6. $4 = 305216
    7. print (xTickCount + xTicksToJump) - xNextTaskUnblockTime
    8. $5 = 55
    Currently we are working around this for when we are debugging but it is painful. Any ideas of what we could look at?We would like to understand why it is happening even if there isn't a better solution.
  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Generally using breakpoints should have no effect here.
    How are you currently working around this issue?
    Do you get the same assert while the application is in active mode and breakpoints are used?
    Currently we assume this issue is related to an interrupt firing before the Systick and xTickCount being incremented without updating the tickless timer.

    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.
  • This assert does not occur if we never go into Idle. It also doesn't not occur if we disable Tickless Idle. That being said I think this assert only runs when FreeRTOS come out of Tickless Idle so of course that should work.

    The assert does not occur if we have no breakpoints set. One of our team has found that setting a breakpoint takes 150ms (was discovered by watching our system power change - or rather stop changing). I am wondering if this happens while we are in Tickless Idle if that is enough to do it. I'm guessing that is the time required for your system to replace the flash instruction to the one required to trigger a SW Breakpoint?

    Our "work around" is really more of a hack. We are looking for the time time to be too long then "adjusting" it before the assert. This is done in fsl_tickless_lptmr.c

    We are using FreeRTOS V9.0.0 so it is possible this has been updated.
  • Hello,

    bill.frank wrote:

    One of our team has found that setting a breakpoint takes 150ms (was discovered by watching our system power change - or rather stop changing). I am wondering if this happens while we are in Tickless Idle if that is enough to do it. I'm guessing that is the time required for your system to replace the flash instruction to the one required to trigger a SW Breakpoint?
    If a SW BP is used J-Link will try to set it as fast as possible. So if this indeed a SW BP then the used target device Flash controller is unfortunately not fast enough which could lead to the mentioned issue.
    To verify if a SW BP is used you could check the Breakpoint tab in the J-Link Control Panel.
    Should a SW BP be used at that point you can force the debug probe to use HW BPs instead e.g. again in J-Link Control Panel in Settings tab under "Flash breakpoints".


    bill.frank wrote:

    Our "work around" is really more of a hack. We are looking for the time time to be too long then "adjusting" it before the assert. This is done in fsl_tickless_lptmr.c

    We are using FreeRTOS V9.0.0 so it is possible this has been updated.
    This sounds like something FreeRTOS should handle itself already. Please understand that we can't give further advice here as FreeRTOS is not our software product.
    From J-Link perspective everything is working as expected and the mentioned issues sound either like target specific issues or application specific ones which we have no control over.

    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.