LPC55s1x Storing Data in Flash and Secure Boot

[MattInSeattle]

Hi, I'm using a 256K LPC55S16 and have some user calibration data stored in the region 0x3C800-0x3CFF. Recall 0x3D000 and beyond is NXP reserved and contains CFPA, CMPA, keys, etc.

I am also using HID bootloader to load a sb2 via ReceiveSbFile command. The SB2 file is prepared via NXP Secure Provisioning Tool 2.1.

Everything works as expected, but when I use ReceiveSbFile in HID bootloader to update with a signed image then the calibration data stored in 0x3C800-0x3CFF is erased.

Is there a way to prevent this from happening?

I am aware of customer regions in CFPA and CMPA, but they are too small.

Thanks!

[MattInSeattle]

BTW, the documentation has an inconsistency. In the PDS (Table 6), the ending address is reported as 0x3FFFF and it says the "last 17 pages (12K) are reserved" yielding 244K of internal flash memory.

In the user's manual (table 4) it says "the last 17 pages (10 KB)" are reserved on the 256K flash device, yielding 246K of internal flash memory.

0x40000 - 10K = 0x3D800

0x40000 - 12K = 0x3D000

Which is correct? A page is 512 bytes, so I don't understand the math above in either case. 17 pages * 512 = 8704 bytes, which seems a strange number.

[MattInSeattle · Accepted solution]

I have figured this out: The provisioning tool creates a file called signed_sb.bd, and inside that file there is a line that says

"erase all"

You can changed that to 

erase 0x0000..0x3C600;

and just that range will be erased. But, when you run the provisioning tool "build image" again, it will revert to the "erase all" which can confuse things. 

Another point of confusion is that if you specify an axf for the provisioning tool input, it appears to silently convert it to a bin and move it to a new directory and that step won't be captured in the scripts. So, the end result if you specify an axf for input is that the tool works, but the scripts don't. The solution is to force a bin in mcuxpresso via post build step, and then use that bin in the provisioning tool. Then the script works. 

One last note of caution to myself: Just exporting the keys to a safe location doesn't seem to be everything you need in the event of a disaster. You also need the SBKEK. 

Clarification on the manual discrepancy noted previously would be appreciated. Thanks