what exactly do I need softdevice_sys_evt_handler for?

[Ron]

Hi

I am using SDK12 with NRF51822,

So far I haven’t initialized the sys_evt_handler (softdevice_sys_evt_handler_set(sys_evt_dispatch)) And my program works fine,

Ive seen a thread mentioning that it is used for NVMC,

but I have used sd_flash_write successfully to write to flash, what will I gain from using this handler when writing to flash or in general?

I would like to get some more understanding about this issue, what exactly are the events this meant to handle, what is its importance? Preferably with some examples.

Thanks!

[Vidar Berg]

Hi,

The Softdevice flash API is asynchronous meaning that the completion of the flash operation will be completed at some point after the program has returned from sd_flash_write(). So to know if a scheduled flash operation was successful or not, you need to monitor the system events through the registered sys event hander. A flash operation should either result in NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_EVT_FLASH_OPERATION_ERROR if the Softdevice was somehow prevented from scheduling the task. 

Our fds and fstorage modules builds on top of the sd flash API where the system events to notify the user whether a flash operation was completed successfully, or if it timed out.

The main reason a scheduled flash operation can fail is if you have a lot of protocol activity, please refer to the Flash API section in the Softdevice specification here for more details: Flash memory API

[Ron]

Hey Vidar

Are there more examples the might necessitate using the sys event handler? other than flash write?

Thanks and have a great day

[Vidar Berg]

We don't have a minimal example that uses the sd_flash_* directly, but you may try to have a look at our BLE examples which use the peer manager module for storing bonding info to flash. The peer manager uses FDS->fstorage->sd flash API to manage NV memory access. In these examples, you can see that system events are forwarded to fstorage through fs_sys_event_handler(). 

[Ron]

Ok, I am asking if there are other types of such events that are NOT related to NVM access 

Is this handler ONLY for NVM handling?

[Vidar Berg]

Sorry, I misread your question. The following events may be forwarded to your sys event dispatcher:

/**@brief SoC Events. */
enum NRF_SOC_EVTS
{
  NRF_EVT_HFCLKSTARTED,                         /**< Event indicating that the HFCLK has started. */
  NRF_EVT_POWER_FAILURE_WARNING,                /**< Event indicating that a power failure warning has occurred. */
  NRF_EVT_FLASH_OPERATION_SUCCESS,              /**< Event indicating that the ongoing flash operation has completed successfully. */
  NRF_EVT_FLASH_OPERATION_ERROR,                /**< Event indicating that the ongoing flash operation has timed out with an error. */
  NRF_EVT_RADIO_BLOCKED,                        /**< Event indicating that a radio timeslot was blocked. */
  NRF_EVT_RADIO_CANCELED,                       /**< Event indicating that a radio timeslot was canceled by SoftDevice. */
  NRF_EVT_RADIO_SIGNAL_CALLBACK_INVALID_RETURN, /**< Event indicating that a radio timeslot signal callback handler return was invalid. */
  NRF_EVT_RADIO_SESSION_IDLE,                   /**< Event indicating that a radio timeslot session is idle. */
  NRF_EVT_RADIO_SESSION_CLOSED,                 /**< Event indicating that a radio timeslot session is closed. */
  NRF_EVT_NUMBER_OF_EVTS
};

where NRF_EVT_RADIO_* may be relevant if you use the Softdevice's multiprotocol support. NRF_EVT_POWER_FAILURE_WARNING if you have called sd_power_pof_enable(), and NRF_EVT_HFCLKSTARTED if you have requested the HF crystal through sd_clock_hfclk_request()