Where should I put manufacturing value?

[rabarton]

I need to be able to reserve some flash to permanently store manufacturing values that will never change. I did this on an nRF51 by reserving a 4KB block and setting the necessary PROTENSET bit in the bootloader to avoid a chance of unintended modification of this flash.  I haven't come across a different method to do this on the NRF52, so still operating under the assumption that this is the safest way to store manufacturing values.  Assuming this, what is the recommended flash space to reserve to have it play nicely with the DFU project?

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.2.0%2Flib_bootloader.html&cp=4_0_1_3_5_0_1&anchor=lib_bootloader_memory

I was thinking I could grab a 4KB block below MBR storage.  To do this and have everything with the DFU project work ok, do I just make sure UICR.NRFFW[1] is set 4KB lower, and NRF_UICR_PARAMS_PAGE_ADDR is still set to the MBR storage block?

A second question is: My bootloader may grow substantially over the lifetime of the product and therefore it would be better to store APP data above the bootloader since I have a better idea of the maximum size of app data over the lifetime of the product. Would something like this violate any assumptions in the DFU libraries or other flash storage libraries?

Thanks.

[Rune Holmgren]

Hi,

(This is a slightly edited version of the nRF52 answer given to the user kentaharada in this question) There are two different answers for systems with and without a bootloader:

Without a bootloader, you should store these data in the last flash page on the device towards the top of the device flash area. Typically 0x3FC00. Ensure that there are no other flash operations in this area done by the application.

With a bootloader, you should store these data in a flash page in the "Application data" area in a region before the FDS pages. The default in the bootloader project is that the "Application data" area is 3 pages determined by the define DFU_APP_DATA_RESERVED. The default in most of the SDK applications using peer_manager is that the FDS uses 3 virtual pages with a page size equal to 1 physical page determined by the define FDS_VIRTUAL_PAGES. If you set the size of the "Application data" area to 1 page larger than the FDS area this additional page can be safely used to store data. It will never be written to by the bootloader because it's in the "Application data" area, and it will never be written to the by the FDS because it's outside the FDS area. I have added an annotated flash map below showing where this page will be:

Best regards,
Rune Holmgren

[rabarton]

Thank you for the explanation Rune. This will work. I'll probably want to grab a 4KB block below the FDS area so I can turn on PROTENSET protection in the bootloader.  Request for a future product would be a few lockable flash/registers so we don't need to use 4KB of flash. As things are designed, we need to estimate future size of the bootloader, and future size of the app FDS data and put our manufacturing values below that which is fragmenting flash quite a bit.

Thanks again for the answer!

[rabarton]

Actually one follow up question is if we were to modify the FDS lib so that we could specify the address range used, do you see any issue with putting manufacturing values just below the bootloader in a 4KB block, and then app data below that? With this change we would have the option to grow the app data in the future. (I realize this may not be trivial with how FDS data is stored in flash)

[yuxin]

good idea

[Rune Holmgren]

Yes, you may do this. The bootloader only knows what region to avoid and is unaffected by where in this region FDS is working. Moving FDS and non-FDS data around within the reserved area is not a problem.

Take care when making such changes though since there isn't any way to recover erased data if your device happens to have an issue with the configuration which causes FDS to overwrite manufacturing values.

Best regards,
Rune Holmgren