This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Breakpoint and reset in SoftDevice addresses 0xA60 and 0xA80

Hi,

Our application sometimes hits a breakpoint in SoftDevice at either address 0xA60 or (less often) 0xA80.

Based on this post https://devzone.nordicsemi.com/f/nordic-q-a/9622/application-debug-with-softdevice I believe that it might be an assert in SoftDevice to do with the realtime BLE requirements. Is this correct? Is this maybe caused by an ISR taking too long meaning SoftDevice cannot do it's BLE tasks?

Any help would be great, thanks.

Parents Reply
  • So, it seems like the watchdog is the cause of the crash. However, this crash only occurs if the system is left idle for hours and then we connect a phone via BLE. We have repeated the test but with the watchdog disabled and the system runs fine (we were hoping that it would get stuck in a loop and we could find it without the Watchdog but it just keeps running).

    Are you aware of anything that might change after a long period of time? We can leave the system for days and it works fine but as soon as we connect a phone it reboots.

Children
  • Is the WD being fed during this idle period? Note that Softdevice tasks such as advertisement events are run in the background without waking the application and will cause the WDT counter to be incremented even if you have enabled the pause on sleep option.

  • I believe the WDT is being fed as we are using FreeRTOS and we have some periodic tasks which run during this period. Currently, the watchdog itself is actually being fed by a periodic task but with it's priority set to the same level as idle.

    That's good to know about it being incremented in the background though, thanks.

  • Ok, good to know that it is being reloaded. I understand it's time-consuming to run this test, but have you tried to extend the WD timeout as well? As for the CPU halting at 0xA80, I recently found out that the debugger will halt the CPU on reset if the "reset" breakpoint is enabled (you can see this breakpoint is disabled in the first screenshot I posted here). The problem is then to find out what caused it to reset in the first place. Maybe it's always by the WD timing out. 

    Has this never happened with the WDT disabled?

  • It does seem that it is a genuine watchdog reset but without the watchdog the system runs fine so it is not stuck but instead it seems that a task is just taking too long meaning the watchdog is not kicked.

    The weird thing is still the fact that it only happens after a phone connects via BLE and the system has been on for a few hours and not every time a phone connects, even though the same tasks run.

    I was wondering if it is the fact you mentioned about the watchdog incrementing in the background so I reduced the watchdog time and let it run thinking it would keep incrementing until it overflowed and caused a reset, but it didn't.

    So, it does seem like it is a problem in our code where something takes too long which we can fix. However, I still don't understand why it only happens after some time, any ideas?

    Thank you!

  • In the failing cases, maybe the WD is already close to expiring when you get the connection event, and the code responsible for reloading is being delayed enough by that to cause a reset. Have you noticed any impact on failure rate if you increase the timeout and or frequency of the periodic tasks that reload the WD?  

Related