Firmware reboots when connecting with APP_TIMER_CONFIG_IRQ_PRIORITY set to 2 or 3.

[CurtisHx2]

Environment:

nRF52833 (BL653 module from Laird)

nRF 5 SDK 17.0.2

S113 v7.2.0

I'm running into a really odd problem that I can't track down.  If I set APP_TIMER_CONFIG_IRQ_PRIORITY to 2 or 3 and try to connect over BLE, the microcontroller reboots.  I looked at the log output in RTT Viewer and there is nothing indicating as to why it rebooted. The typical messages from the GATT when connecting show up and then BOOM! Reset.  Here's the relevant log output:

00> <debug> nrf_ble_gatt: ATT MTU updated to 415 bytes on connection 0x0 (response).
00>
00> <debug> nrf_ble_gatt: Data length updated to 164 on connection 0x0.
00>
00> <debug> nrf_ble_gatt: max_rx_octets: 27
00>
00> <debug> nrf_ble_gatt: max_tx_octets: 164
00>
00> <debug> nrf_ble_gatt: max_rx_time: 328
00>
00> <debug> nrf_ble_gatt: max_tx_time: 2120
00>
00> <info> app: Startup

Setting APP_TIMER_CONFIG_IRQ_PRIORITY to 6 or 7 works fine.  I do see in the documentation that priorities 4-7 are marked as "Software Component only".  What does that mean? I guess based on the behavior I'm seeing is only priorities 4-7 are valid for the APP_TIMER module?

[Vidar Berg]

Hello,

For the app timer I would recommend you keep the priority at '6' (default) because there are several SDK modules that use it internally (peer manager, connection paramater module, bsp, etc). Changing the priority may lead to race conditions and other unforeseen issues as we are not testing for it. Also, it's not allowed to make SV calls (i.e. softdevice API calls) from an interrupt context with higher or equal priority than the SVC IRQ itself. The cortex will raise a fault exception if you do.

Maybe the device is being reset from your hardfault handler?

Best regards,

Vidar