WDT kicking in, disabling NRF_FAULT_ID_SD_ASSERT PC 0xA62

[TomDavies]

The watchdog timer is kicking in our code base and I am having trouble tracking down the cause. In a bit to try and debug the issue I disabled the WDT and now I am getting a NRF_FAULT_ID_SD_ASSERT with the PC at 0xA62.

At this point I'm stuck as to how to keep debugging the issue, are there some common tricks to use to get more info? I see a few posts with the same fault but no reference I can check for this value.

We are using the nRF5 SDK, 17.1.0 and softdevice S140 7.2.0

[Simonr]

Hi Tom

We will need to look into the SoftDevice assert codes on our end to see what it is that's causing this issue. Can you share some details on what your application is doing when running into this error? I assume it is something BLE, but do you have anything more specific to your application?

We'll get back to you tomorrow or on Monday on what the specific SoftDevice assert could mean, as I don't have access to those and will need to ask around internally.

Best regards,

Simon

[Susheel Nuguru]

Is it the the disable WDT that caused the assert? 0xA60 sounds familiar as the softdevice assert handler, not sure why it shows you 0xA62.

Can you start the debugger and see if it is the disabling WDT itself that causes this or it happens after few milliseconds after disabling the WDT?

Any chance you can help me reproduce this on DK?

[TomDavies]

We've been able to reproduce the issue, it does take some trial and error. It was found during testing of our latest planned release.

The application, we've 4 button inputs driving the product(using app button), we're interfacing with a motor controller, UART (data sent from the controller to the mirco), PWM (sets the motor speed) and reading back an RPM (PPI tying the GPIO to a timer and counter). We keep track of the number of times the motor runs, this available as a notification (as well as a number of others) though we aren't connected when we see the issue but the attribute is updated when the motor is stopped.
The issue is trigger by running the motor then a quick series of buttons presses, this stops the motor, it processes a couple of button presses then the WDT kicks in.
I haven't manage to narrow down what is causing the issue.

In this latest release we added the tracking - which uses a counter, a new service with 4 characteristics, we write this value to flash, managed via FDS, though the write is not triggered when we see the issue (it is done at power down).

[TomDavies]

During testing we are seeing the WDT kick in. To try and help identify what the issue is, I rebuilt the firmware where we do not enable the WDT. It is more difficult to get it to fail but when it does, that is when we see assert with the PC @ 0xA62.

I don't think it will be reproduceable on the DK. When I've made changes, to try and identify the issue, quite often it is very difficult, or I'm unable to, reproduce the issue.
I will spend the day tomorrow trying to debug this and will add any further infomation I can gather,

[TomDavies]

So after some more testing.

Our watchdog is actually feed by repeated app timer handler function (that's something that needs looking at after this issue).

What is happening is that when the buttons are pressed, we move into another state where we start another app timer based timer (idle timer). At this point the feed function isn't being called often enough - WDT timeout is 2000ms, we call the feed function every 50ms. After the idle timer is started the feed function timer isn't called again for a little over 5 seconds. For this testing I've disabled to WDT so that I can dig more into the cause.

We have checks for NRF_ERROR_NO_MEM when calling start timer, and check for != 0.

While writing this I realised that the feed function timer handler isn't be called for the length of time that the idle timer is set for.