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

[Susheel Nuguru]

That seems about right that the WDT got triggered and the WDT ISR handler in the MBR (Master Boot Record) is stuck looping. Have you implemented the WDT ISR on the app side?

[TomDavies]

I have, yes. I only saw the assert when I #defined out the init and enable WDT functions.

So the WDT was doing its job, what I need to fix now is the repeated timer waiting(?) until the new timer has run. I receive a success back when starting the new timer but it causes the existing repeated timer to not fire until the new timer expires. I'm not sure how to start debugging this issue.

For clarity, when I disable the WDT for debugging purposes:

Repeated 50ms app timer started

50ms timer firing away

specific button sequence

starts idle timer for n seconds

50ms timer now does not fire (this is where the WDT kicks in if enabled)

idle time expires

50ms timer starts firing again

[Susheel Nuguru]

TomDavies said:

50ms timer now does not fire (this is where the WDT kicks in if enabled)

I think this is the key area of debugging you need to focus now. When it reaches to this state in your application, then pause the debugger and look into the timer registers and see if everything is configured right and if the interrupts are enabled. Other thing to see if this interrupt is being enabled in NVIC using NVIC_GetEnableIRQ and see if this is masked in ARM NVIC level. If there is anything that does not look normal/disabled/masked then you need to find out where exactly that happened. This will be tedious debugging session unfortunately.

[TomDavies]

Thanks Susheel, I'm going to start digging into that now.
Given this is an app timer, rather than hardware (I need to read up more to get a better understanding) given this is based on the RTC, I don't think what you've described is applicable, that would be if it were a hardware based timer? Please correct me if I'm wrong.

If based on the RTC, where/what can go wrong with the app based timers?

[Susheel Nuguru]

TomDavies said:

given this is based on the RTC, I don't think what you've described is applicable

Hmm, Not sure what you mean. You can still read the RTC registers in the debugger and read NVIC register values from the memory read viewer or nrfjprog. The app_timer is based on RTC1 in nRF5SDK. So if your timer callbacks are not being called, we first try to make sure that the source of the interrupts are configured correctly and the interrupts are being fired. If the ISR is being called, then the issue might be something in the callback mechanism. But to reach to that point you need to have some low level checks to see if something else might have not masked the interrupts. If you think that we do not need to dive this deep and you first want to check if the issue is with the callback mechanism, then that is your debugging direction which is one way to do it.