• State Verified Answer
  • Replies 18 replies
  • Subscribers 68 subscribers
  • Views 2914 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235434
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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!

Parents
  • 0

    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

  • 0 in reply to Vidar Berg

    Hey Vidar

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

    Thanks and have a great day

  • 0 in reply to Ron

    Hi,

    1. RTT should not be directly impacted by flash operations. Are you able to debug the application to see if NRF_LOG_PROCESS gets called after you've enabled the sys_event_handler?

    2. No, if you only use sd_flash_* API's you don't. You can just check the event ID in the dispatcher to see if it was NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_EVT_FLASH_OPERATION_ERROR.

    if (sys_evt == NRF_EVT_FLASH_OPERATION_SUCCESS )

    { ..}

    else if (sys_evt == NRF_EVT_FLASH_OPERATION_SUCCESS)

    {..} // flash operation failed. Retry later?

  • 0 in reply to Vidar Berg

    Hey,

    1. It is getting called after enabling the handler, it stops working only after the handler is actually called, I can see that everything else is working via other interfaces including the ble.

    2. Yes, that's exactly what I wanted to do. but as I said, it disturbs the entire logging process.

    Thanks for your help.

  • 0 in reply to Ron

    Hi, 

    Sorry, I lost track of this case. Have you had any progress on this in the meantime? If not, can you try debugging the app in your IDE to see if the program gets stuck in a loop, etc? 

  • 0 in reply to Vidar Berg

    Hey Vidar

    The program definitely is not stuck in a loop, there was no reset, Everything (aside from the RTT connection) continues to function as normal, I maintain BLE connection and am able to command and read my device via BLE normally

    Thanks for your help

  • 0 in reply to Ron

    Hi,

    That indicates that the program is not stuck in a high priority interrupt context at least. Maybe you have some LEDs you can use to indicate when NRF_LOG_PROCESS gets called? Alternatively, try to disable deferred logging (NRF_LOG_DEFFERED) so you don't have to call NRF_LOG_PROCESS. 

Reply Children
Related