• State Verified Answer
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 1442 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 316569
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

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.

Parents
  • +1

    Hi

    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

Reply
  • +1

    Hi

    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

Children
  • 0 in reply to Simonr
    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.
  • 0 in reply to hiroiwas

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

    Best regards,

    Simon

  • 0 in reply to Simonr

    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.

Related
Terms of service