What can interrupt ATOMIC_BLOCK{}?

[jimini]

Are there non-maskable interrupts/events that bypass even this directive?

We’re clocking out some A/D data in an optimized atomic code loop() and getting indeterminant pausing. Sometimes we achieve a determinant “normal” loop, sometimes we don’t. In the included image, the top trace is our loop generated clock I/O pin… A/D data is below.

Argon v.2.0.1 DevOS

There’s also some weirdness that appears as part of an interaction when using the BLE UART, almost as if we get preempted in code by underlying BLE processes.

Any light to shed would be appreciated…
Should we just up to v3?

[rickkas7]

On Gen 3 devices, ATOMIC_BLOCK() doesn't appear to disable all interrupts.

It does call HAL_disable_irq() and HAL_enable_irq().

Those functions on the nRF52 call sd_nvic_critical_region_enter() and sd_nvic_critical_region_exit().

From the nRF52 docs, it says:

Enters critical region.
Postcondition
Application interrupts will be disabled.

This implies that SoftDevice and other high priority interrupts are still enabled, which would match the behavior that you are seeing, but I'm not 100% sure that's what that means.

[jimini]

Thanks for this info, Rick… it aids in our assessment. The additional anomaly that we can observe when sending BLE UART payloads is shown here in this capture:

The upper digital trace (our ATOMIC loop driven clocking) gets preempted when the BLE UART is busy with payload processing, and as shown here there’s 50-60ms of preemption at a minimum when this occurs.

Is this behavior something expected when using the BLE UART services, and would using the BleSerialPeripheralRK library potentially mitigate this behavior?

Thanks in advance.

[rickkas7]

BLE is implemented in the nRF52 radio stack. It’s all implemented in software (nRF52 SoftDevice) and runs at high interrupt priority because of the timing sensitivity, so that would be expected and unavoidable, unfortunately.