Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

About SoftDevice interrupt occupancy time

Hello.

In the BLE software under development, the device uses nRF52840 and uses s140 v7.2.0.

Please tell me the processing time for interrupts used in SoftDevice.

According to the SoftDevice specifications, there are three types of interrupt levels: priority 0, 1, and 4, but the information I want to know is the WORST interrupt occupancy time for each level.

Priority 0 is written as SoftDevice timing critical, I assume this refers to the timeslot API using the timer 0 peripheral and the transmit/receive interrupts from the wireless peripheral.

Priority 1 is written as SoftDevice memory protection, so I understand that this is a fail-safe purpose that will not occur as long as the memory used by SD and APP are separated.

Priority 4 is for API calls and non-time-critical processing, but do all SD APIs go through this interrupt?
Also, what exactly does non-time-critical processing mean?
I believe that this is a callback event from SD via an observer.

Actually, I think the only way is to actually measure it, but if so, please tell me how to measure it for each interrupt level.

For reference, the BLE parameters are listed below.

SCAN_TYPE_ACTIVE 1
SCAN_INTERVAL 20
SCAN_INTERVAL_AFTER_TIMEOUT 20
SCAN_WINDOW 20
SCAN_DURATION 0
SCAN_DURATION_AFTER_TIMEOUT 0
CENTRAL_MIN_CONN_INTERVAL 15
CENTRAL_MAX_CONN_INTERVAL 15
CENTRAL_SLAVE_LATENCY 0
CENTRAL_CONN_SUP_TIMEOUT 500
PERIPHERAL_MIN_CONN_INTERVAL 50
PERIPHERAL_MAX_CONN_INTERVAL 50
PERIPHERAL_SLAVE_LATENCY 0
PERIPHERAL_CONN_SUP_TIMEOUT 4000

* All units are msec.

Best regards.

  • Hello,

    The interrupt processing times for various Bluetooth events are documented in the Bluetooth Low Energy processor usage patterns section of the Softdevice specification. 

    Best regards,

    Vidar

  • Hello, Vidar.

    Listed below, Is my recognize correct?

    • Priority 0 is written as SoftDevice timing critical, I assume this refers to the timeslot API using the timer 0 peripheral and the transmit/receive interrupts from the wireless peripheral.
    • Priority 1 is written as SoftDevice memory protection, so I understand that this is a fail-safe purpose that will not occur as long as the memory used by SD and APP are separated.
    • Priority 4 is for API calls and non-time-critical processing, but do all SD APIs go through this interrupt?
      Also, what exactly does non-time-critical processing mean?
      I believe that this is a callback event from SD via an observer.

    Best regards.

  • Hello,

    hiroiwas said:
    Priority 0 is written as SoftDevice timing critical, I assume this refers to the timeslot API using the timer 0 peripheral and the transmit/receive interrupts from the wireless peripheral.

    The timeslot itself is not running in an interrupt context (Multiprotocol support), but TIMER0 and RADIO are assigned the highest interrupt priority ('0').

    hiroiwas said:
    Priority 1 is written as SoftDevice memory protection, so I understand that this is a fail-safe purpose that will not occur as long as the memory used by SD and APP are separated.

    Yes, the memory protection mechansim will invoke the app error handler if the app attempts to access memory (RAM or peripheral) reserved to the Softdevice. System on Chip resource requirements 

    hiroiwas said:
    Priority 4 is for API calls and non-time-critical processing, but do all SD APIs go through this interrupt?
    Also, what exactly does non-time-critical processing mean?
    I believe that this is a callback event from SD via an observer.

    Yes, all SD APIs are implented as SVCs (Application programming interface)

    hiroiwas said:
    I believe that this is a callback event from SD via an observer.

    The Softdevice events are reported to the application via the SD_EVT_IRQn, which is an application interrupt with priority 6.

    Best regards,

    Vidar

Related