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

How to choose ACCESS_FLASH_PAGE_COUNT and DSM_FLASH_PAGE_COUNT?

These two options in nrf_mesh_config_app are arbitrary for me if I don't understand how they should be sized.

From the documentation of the MESH SDK 3.2.0:

ACCESS_FLASH_PAGE_COUNT: The number of pages of flash storage reserved for the access layer for persistent data storage.

DSM_FLASH_PAGE_COUNT: Number of flash pages reserved for the DSM storage. 

Specifically on the hal.h, there is a #define PAGE_SIZE (0x1000) for the nRF52, which we are using, so I guess each flash page is 4096 bytes.

But is there a formula or rule of thumb to how much memory or how many pages the Access Layer and the Device State Manager needs?

Also, I can program a client with a higher number of access or dsm flash pages than the default (1), but if I reprogram with a different number after one boot, it gives me a mesh assert, that I suspect is because memory was allocated previously on runtime in the first boot and if that memory is changed, some verification fails and the mesh assert is triggered. Am I on the right track?

Thanks,

Rúben

Parents
  • Hi.

    But is there a formula or rule of thumb to how much memory or how many pages the Access Layer and the Device State Manager needs?

    There is no single correct answer to this question. It is entirely application dependent and this will be different for all customers.

    Not sure about the Mesh assert. Did you erase the chip before reprogramming?

    Best regards, 
    Joakim 

  • Then we just set the number of pages to the minimum, let's say 1 each, and keep erasing and reprogramming the chip with a higher number if needed? I was expecting this to be predictable, given the setup of the resources we are requiring, for example number of non virtual addresses and the number of models/elements of the mesh.

    If I erase the chip before reprogramming I can choose any number of pages and it boots fine, the issue only happens if I reprogram with a different number of pages and don't erase the chip previously.

    Best,

    Rúben

Reply
  • Then we just set the number of pages to the minimum, let's say 1 each, and keep erasing and reprogramming the chip with a higher number if needed? I was expecting this to be predictable, given the setup of the resources we are requiring, for example number of non virtual addresses and the number of models/elements of the mesh.

    If I erase the chip before reprogramming I can choose any number of pages and it boots fine, the issue only happens if I reprogram with a different number of pages and don't erase the chip previously.

    Best,

    Rúben

Children
No Data
Related