• State Verified Answer
  • Replies 2 replies
  • Subscribers 75 subscribers
  • Views 755 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262405
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to store data in flash for GATT UDS/UserDataService?

daubsi

I want to implement the GATT UDS/UserDataService according to https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=475617, i.e. with persistent storage of the user's data on a nRF52 DK. Apparently the only way how to store data here on the board itself would be the flash memory. On the other hand I read in the SD documentation that all flash I/O during radio activity is highly risky and likely to fail. How am I supposed to store persistent data in my BLE application under those constraints? What is the best practice here please? The nRF52 DK has no EEPROM or other means of user data storage as far as I know?

This question also arised for e.g. the CSCS: The CSCS sensor is supposed to store the cumulative wheel revolutions persistently and should not reset during sessions, i.e. poweroff/poweron. How would I implement something like that? Is it when the sensor does no longer detect movement activity and shutsdown the BLE connections that it then saves the current state afterwards? 

Might be an option, but I presume it would not be the best solution for the UDS. I guess the user would expect that his data is stored safely the very moment when he says "Yes, please save this data" and the device responds with OK. As far as I understand, at this moment, the device can only cache it, because it cannot actually save to flash yet.

Thank you!

Parents
  • +1

    Hi,

    I'm not sure which part of the softdevice specifications you have read, but you will need to have very high radio activity in order to fully prevent flash-writes to succeed. The writes cannot happen concurrently with radio activity, as the CPU will be halted during writes, but the softdevice will schedule writes between radio activity. The following page describes a set of configurations and the corresponding probability of successful flash write: Flash memory API.

    Flash page erase operations take more time than writes, but if you use FDS for storing data, you should not need to perform erases that often.

    If you have so much radio activity that on-chip flash write is not possible, you could always attach an external SPI based flash for storing persistent data. SPI can operate concurrent with the radio using EasyDMA.

    Best regards,
    Jørgen

Reply
  • +1

    Hi,

    I'm not sure which part of the softdevice specifications you have read, but you will need to have very high radio activity in order to fully prevent flash-writes to succeed. The writes cannot happen concurrently with radio activity, as the CPU will be halted during writes, but the softdevice will schedule writes between radio activity. The following page describes a set of configurations and the corresponding probability of successful flash write: Flash memory API.

    Flash page erase operations take more time than writes, but if you use FDS for storing data, you should not need to perform erases that often.

    If you have so much radio activity that on-chip flash write is not possible, you could always attach an external SPI based flash for storing persistent data. SPI can operate concurrent with the radio using EasyDMA.

    Best regards,
    Jørgen

Children
Related
Terms of service