Write to FLASH inside BLE event

RE: Write to FLASH inside BLE event

Hung Bui — Fri, 17 Feb 2017 12:55:26 GMT

If you are sending lots of byte to the device, I would suggest you follow what we do in our DFU protocol where the DFU master after sending say 200 bytes will stop and wait for a notification from the nRF5 before it keep sending the next 200 bytes. Then you just need a 200 bytes buffer.

RE: Write to FLASH inside BLE event

schef — Fri, 17 Feb 2017 12:16:15 GMT

Thanks for the comment. For example when i want to transfer 50kb of data over BLE. The good thing is that you can't send more the 20 bytes over BLE at once so that means that it will block the CPU for max 5 words which is a very short time i think.

RE: Write to FLASH inside BLE event

Hung Bui — Fri, 17 Feb 2017 12:11:56 GMT

Well, stay for a long time in a interrupt handler may not the very best solution. CPU will be occupied and any other interrupt handler except for APP HIGH will not be executed. Note that there is a chance that the flash write will not be successful. For example when the softdevice return NRF_EVT_FLASH_OPERATION_ERROR then you may end up in a infinite loop.

I still don't know what type of data buffer that you have and which event you have to handle the flash writing. If it's not BLE event, but application event (interrupt from peripheral ) then you can set it to APP LOW priority and you should be able to wait for the event instead of writing and waiting word by word.

RE: Write to FLASH inside BLE event

schef — Fri, 17 Feb 2017 08:44:51 GMT

I think i have found a solution. I write a word for word in memory so i can check if is written with this simple snippet:

sd_flash_write(address, &word, 1);
while (*address != word) {
 nrf_delay_ms(1);
}

For now that i have tested i think it needed around 2ms for one word or write operation.

RE: Write to FLASH inside BLE event

Hung Bui — Fri, 17 Feb 2017 08:36:12 GMT

Sorry I didn't get you at the beginning. Yes, you are correct. This is due to the nature that flash operation will block all CPU activity, so we need to let the softdevice control when to execute flash. And yes, then you will need to wait for NRF_EVT_FLASH_OPERATION_SUCCESS inside sys_evt_handler. And if you put a loop inside the interrupt handler to wait, you will not receive the NRF_EVT_FLASH_OPERATION_SUCCESS event because you still inside the interrupt handler with same priority level.
The local variable with large data you need to store, does it have to be in the BLE event handler ? If it's in the APP Low event handler then it's possible to wait for the event there because APP Low has lower priority than the BLE event.

RE: Write to FLASH inside BLE event

schef — Fri, 17 Feb 2017 07:45:04 GMT

Writen data may get corrupted because of a local variable that you want to write at the time of writing will no longer exist. Which means you have to use a buffer which is not suitable for large data transfer.
I beleve that the event does not come because of a interrupt priority issue.

RE: Write to FLASH inside BLE event

Hung Bui — Thu, 16 Feb 2017 14:26:06 GMT

Hi Schef,

Could you explain a little bit more on:

why "writen data may get corrupted" ? Couldn't you store data in another variable until it's finished writing?
But as some other post mentioned if you call the flash command inside the ble event you don't get the response. =>Not sure if it's correct. Only when you call the API in a APP_HIGH level then hardfault may occur.