Using LESC disrupts system interrupts

Hi there, 

In our device we are using nRF52832 with SoftDevice S112, SDK 17.0.1 and embOS Safe. Up until now we were working with the “Just Works” setting of BLE connection when using pairing through NFC. We recently tried upgrading to “LE Secure Connections” and have encountered an issue where every once in while upon either successful connection or disconnection, the OS system time stops updating and remains constant. This causes all of our SW timers to remain stuck as well since we are calling OS_GetTime32() and eventually leads to a watchdog reset.

 

Since this never happened while using “Just Works” type of connection we suspect that there is some conflict between SoftDevice interrupt priority and embOS. We tried upgrading NRFX_RTC_DEFAULT_CONFIG_IRQ_PRIORITY from 6 to 2 (0,1 are reserved to SoftDevice) but it did not help.

 

Here’s a log example of how it looks like:

 

I suspect something during those 20 ms between the established connection and the next event triggering is causing some collision between interrupt priority. Any idea what happens behind the scenes during that time?

Speaking with embOS, they asked to check if the SoftDevice stack modifies PRIMASK and/or BASEPRI.

Any insight would be appreciated.

Parents
  • When you switch to LE Secure Connections, Nordic’s S112 SoftDevice must do a full P-256 key exchange in software, which on the M4 takes about 20 ms and during that entire crypto operation it disables all interrupts using PRIMASK. From your RTOS’s viewpoint, your RTC tick interrupt simply never occurs for those 20 ms, so your software timers stop advancing and the watchdog trips. Raising the RTC’s NVIC priority won’t help, because PRIMASK blocks everything.

    The usual fix is to stop depending on interrupt-driven ticks for your time base. Instead, read a free-running counter (e.g. the raw RTC COUNTER register), or move your tick to a PPI+TIMER scheme that latches time without needing an IRQ, so that time still marches on even while SoftDevice is crunching its ECDH.

Reply
  • When you switch to LE Secure Connections, Nordic’s S112 SoftDevice must do a full P-256 key exchange in software, which on the M4 takes about 20 ms and during that entire crypto operation it disables all interrupts using PRIMASK. From your RTOS’s viewpoint, your RTC tick interrupt simply never occurs for those 20 ms, so your software timers stop advancing and the watchdog trips. Raising the RTC’s NVIC priority won’t help, because PRIMASK blocks everything.

    The usual fix is to stop depending on interrupt-driven ticks for your time base. Instead, read a free-running counter (e.g. the raw RTC COUNTER register), or move your tick to a PPI+TIMER scheme that latches time without needing an IRQ, so that time still marches on even while SoftDevice is crunching its ECDH.

Children
No Data
Related