• State Verified Answer
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 1444 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.

  • 0

    Hi 

    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

  • 0 in reply to Simonr

    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.

  • +1

    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

  • 0 in reply to Simonr

    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.

Related
Terms of service