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?
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:
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:
Cheers,
Håkon
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:
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:
Cheers,
Håkon
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.
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.
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.
Yes, that's correct. Here's a list of the peripherals that the softdevice uses:
Those marked blocked are all (except FICR) able to generate events and interrupts.
