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

Mesh SDK - NRF52840 flash page issue

I am setting up a programming script for our devices.  
Memory layout is as follows:

Address Size
MBR+SoftDevice 0x00000 0x26000
Application 0x26000 0x66000
DFU Swap Space 0x8C000 0x66000
Persistent App Data 0xF2000 0x2000
Nordic Mesh Info 0xF4000 0x4000
Nordic Bootloader 0xF8000 0x6000
Bootloader Settings 0xFE000 0x2000

Programming the following items: SD, bootloader, our application, and device page produced by device_page_generator... The device functions as desired.
The issue is when I attempt to add the persistent app data pages, starting at 0xF2000.
It seems that something is using that page (and F3000):

J-Link>mem8 F2000 1024

000F2000 = 08 04 10 10 01 00 FF FF FF FF FF FF FF FF FF FF
...
000F2FF0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000F3000 = 08 04 10 10 01 00 FF FF FF FF FF FF FF FF FF FF

I thought I had properly accounted for the flash pages required by mesh.  
Calling the following functions shows that the DSM starts where I expect:
dsm_flash_area_get() = 0xF4000
net_state_flash_area_get() =  0xF5000
flash_manager_recovery_page_get() = 0xF6000

What have I missed?  What is using the flash pages at 0xF2000 and 0xF3000

Thanks.

Mesh SDK v3.1.0
nRF5 SDK v15.2.0

Parents
  • You seem to have missed mesh_config. You can use mesh_stack_persistence_flash_usage() to get out the actual memory usage of the mesh.

  • In mesh_sdk/doc/how_to_nordicSDK.md there is the following information:
     

    Furthermore, when writing to flash, ensure to not write or erase areas utilized by the mesh stack
    modules and the bootloader (if present). By default, the mesh modules utilize the last `x` number of
    pages before the start of the bootloader, if present, or the last `x` number of pages of the
    available flash on the Nordic SoC.
    The value of `x` depends on the configuration of the mesh stack and can be calculated by:
    
        x = 2 + ACCESS_FLASH_PAGE_COUNT + DSM_FLASH_PAGE_COUNT

    Based on my mesh sdk configuration, x = 4, which is why I have allocated 4 pages in my layout.

    In mesh_sdk/doc/libraries/flash_manager.md there is the following information:

    By default, the defrag recovery page is the last page before the bootloader starts, or the last page in device flash if the bootloader is not present (determined by the `UICR->BOOTLOADERADDR` register). This location can be overriden by defining `FLASH_MANAGER_RECOVERY_PAGE` in the compiler defines. Note that the recovery page should be the same page in every iteration of the firmware, to avoid loss of backed up recovery data.

    So, this recovery page is not part of the 4 pages mentioned earlier in how_to_nordicSDK.md?
    Also, I expect the recovery page to be at 0xF7000 not 0xF6000, since the bootloader begins at 0xF8000.  If the recovery page is actually at 0xF6000, what is using 0xF7000?

    I have added the call to mesh_stack_persistence_flash_usage, and it returns the following values: start(0xF2000), size(0x5000).

    So 5 pages are being used by SDK components.  What in the configuration accounts for the extra page?
    I expected it to use 4 pages based on the information in how_to_nordicSDK.md.  

    Thanks.

  • can you offer any additional comments on this? thanks!

  • Hi,

    Sorry for the late response.

    It seems like you found some outdated documentation, I have reported this internally. It is the MBR that are using 0xF7000. You can have a look at the SDS for more information. The extra page you are seeing are for mesh_config.

  • I thought the MBR and bootloader settings were the last two pages in flash, FE000-FF000?  Has this changed?

    Note that this is for the NRF52840 device.

Reply Children
No Data
Related