Regarding DFU operation while using BLE

[hiroiwas]

Hello.

This is a question regarding fstorage during DFU on S140 / RF5 SDK 17.1.0.

I think that conflicts are mediated within the DFU when writing to Flash during BLE communication, but according to the text here, ``Using too aggressive scan or advertising intervals, or running multiple connections, can influence the success of a flash operation."

So I have a few questions.

・Specifically, what operation of BLE conflicts with writing to FLASH?
・What happens if there is a conflict? (For example, writing fails, BLE communication is delayed, etc.)
・Are there any guideline values for block size and writing frequency for writing to FLASH, and parameters for BLE communication that can be used without problems?

In our system, the SCAN interval and WINDOW width are 20ms, the connection interval is 15ms, and we are operating BLE with advertisement (NONCONN_IND) at 100ms intervals.
It is assumed that the updater can be written to FLASH using DFU without affecting this BLE communication.
For example, is it possible to sequentially write data received at a frequency of about 256 bytes/second to flash using DFU?

best regards.

[Simonr]

Hi again

I think you worry for nought here. The SoftDevice won't schedule any other operations for when a flash write/erase is happening.

Yes, incoming BLE events will be blocked while these are ongoing, but if you're I.E. in a connection you can make sure this won't be an issue by setting the connection supervision timeout and retry number higher so that the other side of the connection will retry if it doesn't receive an ACK from your device.

It will not be possible to both do flash access and avoid BLE to ever be blocked I'm afraid.

Best regards,

Simon

[hiroiwas]

Hello Simon.

got it. It was as expected.

We plan to actually measure how much it is blocked and how much of an impact it has on BLE communication, and reflect it in the design.

thank you very much.