sd_flash are events scheduled or interrupts?

[Jordan Archer]

Are sd_flash events NRF_EVT_FLASH_OPERATION_SUCCESS and NRF_EVT_FLASH_OPERATION_ERROR  actual events, schedule and only run when app_sched_execute is run.  Or are they run from and interrupt handler.

Basically, is the NVM event handler run in and interrupt handler?

[Håkon Alseth]

Hi Jordan,

The sd_flash_* API is a scheduled operation, which will be queued by the application and executed at a later point, in-between your bluetooth events, so that your connection(s) is "the least disrupted". You'll then get a event back to the application with either _SUCCESS or _ERROR from the SoftDevice-handler.

More info on how the softdevice handles these events are described here:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.sds/dita/softdevices/s130/processor_avail_interrupt_latency/flash_usage_patterns.html?cp=2_3_1_0_15_2_0

Why does the softdevice handle flash operations?

It is mainly because the hardware peripheral for flash erase or write will halt the CPU when it's on-going. In this sense, you can look at the NVMC-peripheral as a blocking interrupt, which will halt the CPU until the flash operation is finished. Any pending event occurring while the flash-operation is on-going will be handled afterwards, like a TIMERx event or a UART_RX event. This is because peripherals runs independent of the CPU state. This is similar for a normal debug session, where you halt the CPU, but all enabled peripherals still runs (timer keeps counting, rtc keeps ticking, etc.)

As a historical aspect, early versions of the first SoftDevice (back in '11 or '12, for the nRF51-series) did not handle flash operations in the stack, so the application needed to do this when a connection-interval was finished. However, this might cause timing-errors if you used a lower connection interval, like 7.5ms, and triggered an _ERASE operation. The flash operation handling was therefore moved to the stack, so that it could handle such a scenario in a more graceful way, and not cause assertions in the application for tight timing scenarios.

The hardware peripheral that triggers flash operations is the NVMC, which you can read about here:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nvmc.html?cp=2_1_0_10#concept_pcl_wbz_vr

Cheers,

Håkon

[Jordan Archer]

That doesn't answer the question. 

I understand softdevice is scheduling the flash operation in the background, due to BLE management requirements.  But that doesn't answer the relationship of the sd flash event notifications to the application and use of app_sched_execute.  

I'm trying to understand if my application code flash event handling, will be asynchronously called.  If it is, I need to protect parts of what I'm doing with critical sections. 

This breaks down into what is the relationship in scheduling between app_sched_execute (or app events), sd events and hardware level interrupts.  Are sd events and app events synchronized?  Or should everything at the app level treat sd events being signaled as asynchronous (interrupts) in execution. 

[Håkon Alseth]

if you use the app_scheduler, and you have setup your softdevice handler to use it as well, all Softdevice events (SoC, BLE, ANT, System) will be scheduled through the app_scheduler, and handled in a FIFO principle. Softdevice interrupts are asynchronous to the application, and it is not recommended to do a global __disable_irq(); while the softdevice is running. Please note that the CRITICAL_REGION_ENTER/EXIT API in the SDK is provided to disable application interrupts, and not softdevice interrupts.

[Jordan Archer]

Thanks, that helps.  

But, I could use one clarification.  When you say softdevice interrupts, do you mean interrupts that softdevice is handling?  i.e the radio operations.

[Håkon Alseth]

Yes, that's correct. Here's a list of the peripherals that the softdevice uses:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.sds/dita/softdevices/s130/sd_resource_reqs/hw_block_interrupt_vector.html?cp=2_3_1_0_6_0 

Those marked blocked are all (except FICR) able to generate events and interrupts.