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]

Generally yes. But it is possible to use the radio in allocated "timeslots" through the Softdevice's multiprotocol feature. Multiprotocol support

[Ron]

Thank you.

[Ron]

Hey Vidar, 

A few more questions , 

1. setting softdevice_sys_evt_handler - sys_evt_dispatch, disturbs RTT Jlink after a I preform a write to flash. why is that? I see it got there and printed the last log from there, the software still works but as I said my JLINK RTT viewer stops showing updates, closing and opening the RTT viewer does not help.

2. I don't implement bonding currently, so I think I have no need for pstorage, in the example of implementation of sys_evt_dispatch that I saw there was 2 calls for : pstorage_sys_event_handler(sys_evt) and ble_advertising_on_sys_evt(sys_evt), do I need to call them in my application? (I also don't use multi protocol)

Thanks!

[Vidar Berg]

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?

[Ron]

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.

[Vidar Berg]

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? 

[Ron]

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

[Vidar Berg]

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. 

[Ron]

Hey,

What Im using is LOG_INTERNAL, it just calls it directly.

I just found out something interesting,

The problem is not happening like J-Link RTT Viewer V6.22g ,

It does happen with J-Link RTT Viewer V6.33i which I have been using as default. 

I am just turning off the V6.33i and switch on the V6.22g  and see the messages just fine..

If that gives you any idea regarding what is happening..

Thanks again!

[Vidar Berg]

Hi,

Ok, it seems like it's a problem with RTT viewer then. Maybe you have more log messages when you enable the sys event handler. Anyway, I have had better luck with using the RTT client from a terminal window. But note that you need to be in a debug session for log messages to be routed to the client.