S140 7.2.0 softdevice panic at 0x1786A

[daagaak]

I'm running into a problem where my softdevice is triggering the fault handler but only when I'm also using the USBD. The panic info is below, I've tried to double and triple check that I'm not mis-masking interrupts.

id=1, pc=0x1786A, info=0x0

What does this fault mean?

[Kenneth]

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.

[daagaak]

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

[Kenneth]

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

[daagaak]

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?

[Kenneth]

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

Kenneth

[daagaak]

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

[Kenneth]

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