S140 7.2.0 softdevice panic at 0x1786A

RE: S140 7.2.0 softdevice panic at 0x1786A

Kenneth — Mon, 01 Feb 2021 13:13:42 GMT

Both asserts are consistent with the application in some way are preventing the LL to run, causing the LL to be delayed and thereby the softdevice asserts, e.g. check masking of interrupts and/or interrupt priority levels.

If you unable to find the cause, I guess we need some firmware we can compile and run here to recreate it.

Kenneth

RE: S140 7.2.0 softdevice panic at 0x1786A

daagaak — Thu, 28 Jan 2021 19:27:26 GMT

I checked my terminal output and it's 0x15A98. this is with s140_nrf52_7.2.0_softdevice.hex

RE: S140 7.2.0 softdevice panic at 0x1786A

Kenneth — Thu, 28 Jan 2021 18:58:32 GMT

Can you check if you meant 0x15A88, instead 0x15A98?

Kenneth

RE: S140 7.2.0 softdevice panic at 0x1786A

daagaak — Wed, 27 Jan 2021 21:00:58 GMT

Yeah, it's a testbed of a bluetooth keyboard. It only uses USBD, RTC1 and GPIOTE. I've set them all to run at priority 6.

There's no scheduler, the application runs with cooperative multitasking all in thread execution. Interrupts from the USBD/RTC1/GPTIOE are only used to briefly flag a ready signal for the appropriate co-routine.

What do these two fault addresses mean? Are they indication of violating interrupt priority/scheduling?

RE: S140 7.2.0 softdevice panic at 0x1786A

Kenneth — Wed, 27 Jan 2021 17:39:06 GMT

I linked to the wrong example, maybe you can check out: \examples\peripheral\usbd_ble_uart

Can you tell me a bit more about your application, in terms of peripherals used, any scheduler/rtos, pa/lna etc?

Kenneth

RE: S140 7.2.0 softdevice panic at 0x1786A

daagaak — Wed, 27 Jan 2021 15:31:02 GMT

Thanks for the follow up. It doesn't look like ble_app_uart uses USBD? However, I did find the NRFX_USBD_CONFIG_IRQ_PRIORITY define in sdk_config and it suggests using priority 6. I moved my USBD priority down to 6, it was at 2. I've confirmed in the debugger that the priority level for IRQ 39 is set. Sadly, I still get the fault_handler.

The fault handler seems to alternate between 0x15A98 and 0x1786A

RE: S140 7.2.0 softdevice panic at 0x1786A

Kenneth — Wed, 27 Jan 2021 13:19:29 GMT

Can you look into the interrupt priority used by the USBD? For instance the ble_app_uart show a combination of BLE and USB, and you can find defines in sdk_config for USBD.