This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NVMC Write Time With ZigBee Coordinator and Bluetooth Multiprotocol

I have ~600 bytes of configuration data total that needs to be saved each after a sensor joins the Zigbee network, details like:

  • IEEE addr
  • end point
  • Join state details
  • etc

The 600 bytes is the entire array for all the devices that have joined the coordinator.

Should I be concerned about the write time this much data while running the ZigBee stack as a coordinator while in a Bluetooth connection?  The connection interval is 0.1s to 0.2s.

Thanks,

Parents
  • Hi,

    Sorry for the late reply. I see you have decided to go another way, but anyways I am attaching my answer to the original question:

    Writing to NVMC goes through the softdevice API, and will be scheduled between BLE events, so it will take away capacity from the 802.15.4 stack. Flash operations will stop the CPU for a quick moment, so Zigbee operations will be block for as long as the writing operation takes place.

    This can become a problem or not depending on the amount of data you are writing and how often. Page erase is 80-90ms (max) and the probability for flash operation sucess can you find here:

    Another thing to keep in mind is that it's recommended to use FDS for writing data, as writing directly to the flash may be risky, it can lead to flash wearing e.g. SD backend should be used here as well.

    Also amount of devices may be changing, adding and removing devices should be consider as multiple read/write operations, and because you want to implement this at the coordinator you need to keep an eye of how much space in flash you need for storing all this data based on max network size.

    See also multiprotocol considerations: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fble_154_multiprotocol.html&cp=7_3_4_0_1_1&anchor=ble_154_multiprotocol_considerations

    See also the "limitations" section in the SDK T&Z v4.1:

    - Zigbee performance might be affected by heavy flash operations.
      Zigbee stack subsystem periodically runs the migration process.
      As the flash operations block the CPU, this may affect Zigbee time-critical processes (Association, Rejoin, Leave, GreenPower Commissioning, among others) if these operations occur at the same time with such processes.
      The likelihood of this happening is low, but this may occur if the Parent device is joining 20+ devices one-by-one without delays, or in other cases of mass NVRAM operations in intersection with the mass radio operations.
      This issue does not affect the steady state operation. (KRKNWK-3263)

    When all that is said, if you write 600 bytes a few times each day it shouldn't be a problem. It will take a max of 6.15ms to write 600 bytes (150 words). If you plan to write 600 bytes each second then it wouldn't add up. 

    Best regards,

    Marjeris





Reply
  • Hi,

    Sorry for the late reply. I see you have decided to go another way, but anyways I am attaching my answer to the original question:

    Writing to NVMC goes through the softdevice API, and will be scheduled between BLE events, so it will take away capacity from the 802.15.4 stack. Flash operations will stop the CPU for a quick moment, so Zigbee operations will be block for as long as the writing operation takes place.

    This can become a problem or not depending on the amount of data you are writing and how often. Page erase is 80-90ms (max) and the probability for flash operation sucess can you find here:

    Another thing to keep in mind is that it's recommended to use FDS for writing data, as writing directly to the flash may be risky, it can lead to flash wearing e.g. SD backend should be used here as well.

    Also amount of devices may be changing, adding and removing devices should be consider as multiple read/write operations, and because you want to implement this at the coordinator you need to keep an eye of how much space in flash you need for storing all this data based on max network size.

    See also multiprotocol considerations: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fble_154_multiprotocol.html&cp=7_3_4_0_1_1&anchor=ble_154_multiprotocol_considerations

    See also the "limitations" section in the SDK T&Z v4.1:

    - Zigbee performance might be affected by heavy flash operations.
      Zigbee stack subsystem periodically runs the migration process.
      As the flash operations block the CPU, this may affect Zigbee time-critical processes (Association, Rejoin, Leave, GreenPower Commissioning, among others) if these operations occur at the same time with such processes.
      The likelihood of this happening is low, but this may occur if the Parent device is joining 20+ devices one-by-one without delays, or in other cases of mass NVRAM operations in intersection with the mass radio operations.
      This issue does not affect the steady state operation. (KRKNWK-3263)

    When all that is said, if you write 600 bytes a few times each day it shouldn't be a problem. It will take a max of 6.15ms to write 600 bytes (150 words). If you plan to write 600 bytes each second then it wouldn't add up. 

    Best regards,

    Marjeris





Children
No Data
Related