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

[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).