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

fail to using FDS in uart, mesh program

noam

HI,

i'm using SDK 15.2.0 and MESH SDK 3.1.0.

my program using the uart to get data from a sensor and sending it over the mesh network.

now i'm trying to write to the flash and read the this data.

when i'm using the flash_manager has the example here all work fine but i asked about it here and told me not to using the flash manager...(Why?How i can remove all the mesh network settings for the device ?).

so i tried to use the FDS has the support recommend me, but its not work for me when i try to initialize the fds the same way the example in SDK(<InstallFolder>\examples\peripheral\flash_fds) the program crash and i cant write and read from the flash. when i remove the uart option its work fine.

maybe someone know whats the problem ? there is a example to integrate uart mesh and FDS?

thanks!!!

Parents
  • +1

    Hello,

    Well. You mentioned that you used the function flash_manager_remove() to delete the data that you want to store. While this may work, you may or may not delete the mesh network keys. The flash_manager can have several instances, so look at them as cabinets. If you use only one cabinet, where you store all your network keys, and also your custom data, and you use flash_manager_remove() you will basically throw away the entire cabinet. So the next time you power on the device, it will no longer have the network data, and you have to perform the network provisioning again. 

    If you have two flash manager instances, that will be like having two cabinets. If you use a different instance than the one that stores the network keys, you can throw that instance/cabinet out the window, and you still have your network keys. 

    However, as mentioned in your previous thread, by removing this instance, and adding it again, you will use the same flash area over and over, and you will wear up the flash unnecessarily quick. As you can see here,  we can only guarantee 10 000 write cycles on the flash on the nRF52832 (although it will probably be more). To prevent flash wear, the flash manager uses wear leveling. This doesn't work if you just remove the instance of the flash manager. 

    What you should do:

    Initialize one instance of flash manager that you can use for your custom application data. If you want to update it use flashmanager_entry_alloc to copy the desired new data to the entry buffer, and call flash_manager_entry_commit to actually update the entry. This way, the flash manager will mark the old entry as "deleted" or "invalidated", and when one flash page is used up, it will run through the entries, move the ones that are still valid, and delete the ones that are invalidated. Now you update a value many times before you need to actually erase the flash page, which significantly increases the lifetime of the flash. 

    I hope this cleared things up a bit. Be aware that this is a bit different from the fds in the "normal" sdk, but it basically does the same thing. You can use the flash manager if you use the Mesh SDK.

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    Well. You mentioned that you used the function flash_manager_remove() to delete the data that you want to store. While this may work, you may or may not delete the mesh network keys. The flash_manager can have several instances, so look at them as cabinets. If you use only one cabinet, where you store all your network keys, and also your custom data, and you use flash_manager_remove() you will basically throw away the entire cabinet. So the next time you power on the device, it will no longer have the network data, and you have to perform the network provisioning again. 

    If you have two flash manager instances, that will be like having two cabinets. If you use a different instance than the one that stores the network keys, you can throw that instance/cabinet out the window, and you still have your network keys. 

    However, as mentioned in your previous thread, by removing this instance, and adding it again, you will use the same flash area over and over, and you will wear up the flash unnecessarily quick. As you can see here,  we can only guarantee 10 000 write cycles on the flash on the nRF52832 (although it will probably be more). To prevent flash wear, the flash manager uses wear leveling. This doesn't work if you just remove the instance of the flash manager. 

    What you should do:

    Initialize one instance of flash manager that you can use for your custom application data. If you want to update it use flashmanager_entry_alloc to copy the desired new data to the entry buffer, and call flash_manager_entry_commit to actually update the entry. This way, the flash manager will mark the old entry as "deleted" or "invalidated", and when one flash page is used up, it will run through the entries, move the ones that are still valid, and delete the ones that are invalidated. Now you update a value many times before you need to actually erase the flash page, which significantly increases the lifetime of the flash. 

    I hope this cleared things up a bit. Be aware that this is a bit different from the fds in the "normal" sdk, but it basically does the same thing. You can use the flash manager if you use the Mesh SDK.

    Best regards,

    Edvin

Children
No Data
Related