sd_flash_write writes corrupted data when BLE is enabled

[David]

Hi,

I wrote some code that writes to the flash perfectly when BLE is not enabled but when it is enabled, some of the data are correct while others are either missing or shifted to a later address. Below is a snippet of the code:

uint32_t retval;
while(NRF_ERROR_BUSY == (retval = sd_flash_write(p_dst, p_src, num_words)));
ASSERT(NRF_SUCCESS == retval);

I'm trying to avoid pstorage since I'm want to write to a contiguous block of flash much greater then the page size.

Thanks.

[David]

I've tried rewriting it with the sys_evt_handler. The code now looks like this:

while(!flash_done);
flash_done = false;
retval = sd_flash_write(p_dst, p_src, num_words);
ASSERT(NRF_SUCCESS == retval || NRF_ERROR_BUSY == retval);
wait_us(500);

Inside the handler, if I receive a NRF_EVT_FLASH_OPERATION_SUCCESS then I set flash_done = true. I've noticed that when the handler is called the flash process is still not finished so a I had to add a small delay to make back to back writes work. Also, the sys_evt_handler is not called if I'm servicing the ble_evt_handler so the above snippet will get stuck in the loop if I'm trying to, for example, log the connection info when onConnectionCallback() is called.

[RK]

Ah - if you're using the device manager or anything else which uses pstorage under the hood then you have a massive conflict between what you're doing and what it's doing. It registers a handler for SWI2 and processes ble and system events and expects that any flash callbacks come from the pstorage module. That might explain why you don't see system events too, pstorage may have eaten them. if you have pstorage linked in you really can't use your own flash storage.

[David]

I'm setting the handler with softdevice_sys_evt_handler_set() after I initialize the BLE and I was able to confirm that the SD is calling my handler instead of the pstorage's throughout the lifetime of the code. With the slight delay after the sd_flash_write() call, I'm able to write to the flash properly except when I'm inside another callback such as onConnectionCallback() as I've explained above. And occasionally I would get into a hardfault if I try to ble.updateCharacteristicValue() after I call sd_flash_write().

[RK]

I'm out of ideas then. I back-to-back flash writes in the callback when i receive SUCCESS, no delay necessary and I've never yet received a BUSY either nor had a bad write nor an ERROR, that I've seen anyway. I'm writing less data at a time than you are but still a substantial amount. I get system events posted whether I'm servicing BTLE or not and haven't been in the hardfault handler for a while. Have you managed to work out what the hardfault reason was (which can be hard)?

The whole requiring a delay after you get a flash write success message is suspicious, when you get that message, the sd flash write has finished. There's something else going on here which may or may not be directly related to flash storage but is affecting it, I can't suggest what.

[David]

I don't know much about the hardfault other than it seems to happen if I rapidly call sd_flash_write() and ble.updateCharacteristicValue() multiple times and it faults on the update function.