Regarding DFU operation while using BLE

RE: Regarding DFU operation while using BLE

hiroiwas — Tue, 21 Nov 2023 01:49:14 GMT

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.

RE: Regarding DFU operation while using BLE

Simonr — Mon, 20 Nov 2023 12:31:34 GMT

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

RE: Regarding DFU operation while using BLE

hiroiwas — Fri, 17 Nov 2023 09:16:02 GMT

Hello Simon.

Please let me check.

I understand that exclusive control is performed using the timeslot API, but fstotage ultimately calls sd_flash api.

As mentioned above, sd_flash_write and sd_flash_page_erase written, "all interrupts will be blocked for a predictable time", so there is a chance that they will block during the write operation, regardless of schedule. I'm worried that there is.

Specifically, with erase, won't all events including BLE be blocked for 85ms, which is equivalent to one page?
It would be nice if BLE is never blocked from sd_flash_page_erase to NRF_EVT_FLASH_OPERATION_SUCCESS.

Best regards.

RE: Regarding DFU operation while using BLE

Simonr — Fri, 17 Nov 2023 08:32:11 GMT

The fstorage uses a timeslot API when the SoftDevice is part of the application to make sure both the flash operations and radio operations are able to work uninterrupted. The scheduling of the SoftDevice is explained in the SoftDevice specification here. So when the flash is writing the BLE will indeed not be communicating at the same time, as it will be waiting for a new timeslot when the flash is finished with its operations.

Best regards,

Simon

RE: Regarding DFU operation while using BLE

Simonr — Thu, 16 Nov 2023 12:04:48 GMT

I will have to discuss this with one of my colleagues that are out of office today before coming back to you. Sorry for the delay and any confusion here. I'll clear it up for you (and me) ASAP.

Best regards,

Simon

RE: Regarding DFU operation while using BLE

hiroiwas — Wed, 15 Nov 2023 09:29:33 GMT

Hello again.

From the above answer, I thought that BLE communication was prioritized over fstorage, but the Note of sd_flash_write written, "This call takes control over the radio and the CPU during flash erase and write to make sure that they will not interfere with I found the following statement: the flash access. This means that all interrupts will be blocked for a predictable time."

If this note is correct, it can be understood that BLE interrupts will stop and communication will not be possible during flash writing.

Is this correct?

The system currently being designed writes in units of 256 bytes (64 words), so based on the nRF52840 specs, it is expected that the write time will be around 2.6 ms.

Will this write affect BLE communication with a scan interval of 20ms and a connection interval of 15ms?
For example, when a write occurs, does one interval is skipped, or does the write extend the interval.

Additionally the erase time was even longer, reaching 85ms per page according to the specs.
Since the minimum unit of erasing is a page, I think that BLE is prohibited for at least 85ms.

Best regards.

RE: Regarding DFU operation while using BLE

Simonr — Thu, 26 Oct 2023 07:05:23 GMT

Yes, that's correct. Please let me know if there are any follow-ups.

Best regards,

Simon

RE: Regarding DFU operation while using BLE

hiroiwas — Wed, 25 Oct 2023 00:12:26 GMT

Hello Simon.

Thank you for your prompt reply. From the answers,

I found that BLE communication has priority over fstorage, so I think the only thing left to do is adjust the number of fstorage retries.

If you run into any problems with the actual code, please ask again.

RE: Regarding DFU operation while using BLE

Simonr — Tue, 24 Oct 2023 14:33:40 GMT

1. The BLE stack requires the SoftDevice and radio peripheral, which in turn requires the HF clock and CPU priority, which the FLASH operations also require, and these will cause a conflict if the flash storage and/or scan/advertising parameters are too aggressive.

2. I think the question on conflicts is answered a bit further down in the documentation you quote. The SoftDevice will retry getting FSTORAGE, and if it can't get access, eventually time out when the NRF_FSTORAGE_SD_MAX_RETRIES is met.

3. Not really, it will all come down to your entire project, and most of the parameters you mention look good, but I'd maybe recommend setting the scan and window interval a bit higher (50-100ms perhaps) to avoid unnecessary conflicts with the FLASH.

Best regards,

Simon