SEC V7 LPC55S69 Unable to Set Valid Start Address

[Ben_Sanda]

Hello,

I'm using the MCUXpresso Secure Provisioning Tool V 7.0 [b230713] and am trying to create a secure boot image for the LPC55S69. I can generate all the keys but am stuck trying to set the start address. I have a compiled binary file (.bin) that was generated using IAR Workbench which has a load address of 0x0 in internal flash. When I try and put 0x0 as the start address in the SEC tool it reports it as invalid and give the tool tip: 

"ERROR: Incorrect address value or invalid image content. Invalid image start address. Based on the detected application entry point address of 0x0005F9E9 and image size 248285, the start address shall be in the range 0xA96C-0x0005F9E9"

I have verified the header of the built binary and address 0x34 = 0x0 which per the LPC55S69 datasheet states is the imageExecutionAddress in the header. I have tried the entry point address which the error message indicates but that is also invalid (out of valid memory range for the device). I have the settings set to XIP from internal flash and boot mode = signed. See attached screenshot.

Is there something I'm missing or some other step that is required?

[marek-trmac]

Hi Ben,

the error message says, that start address + image size < entry point address. - this would mean that there is no code at the entry point address.

MCUXpresso Secure Provisioning Tool retrieves reset vector of the application (entry point) and in your case entry point was 0x0005F9E9. I suspect this is incorrect, can you please check? It is located at the offset 0x4 of the application image.

MCUXpresso Secure Provisioning Tool allows to use the following application file formats on a build tab: ELF, HEX, S19 and BIN. The BIN does not contain information about the address, so you must enter start address manually. All the other formats contains the address, so it is taken from the image. Kindly check if the file extension matching the file format.

For the other your questions: Start address 0x0 should be correct value. imageExecutionAddress is not evaluated before the build. On your screenshot, all the settings are correct (you need to enter SBKEK too). About required steps, please follow documentation, chapter 6.4.3.2.

[Ben_Sanda]

Marek,

Thank you for the reply. In this case I'm using a raw binary image produced by IAR workbench and the header appears as in the attached screen shot. Offset 0x4 does equal  0x0005 F9E9 which is the initial PC address per the datasheet. Looking at the .map file for the build that is the address of the start vector startup_LPC55xx_core1. So that seems correct.

In my case the binary image is actually loaded at 0x10000 in internal flash and then booted via a second stage bootloader (the linker is correctly configured for this). So the base load address of the image is 0x10000. Perhaps that's why it thinks the address is invalid? It thinks the binary is being loaded at 0x0, not 0x10000 and thus start address + image size < entry point address is not valid.

I then modified my unsigned binary image to set offset 0x34 = 0x1000 as this should be the image execution address per the datasheet. The security tool still didn't like it and had the same errors. If I put in 0x0 for start address it says it's an invalid range, if I put 0x10000 as the start address it says the expected offset in target memory is 0x0 but found 0x10000, and if I put 0x5 F9E it says the image size is greater than the total memory size. Perhaps the security tool just can't handle images that aren't loaded at address 0x0?

[liborukropec]

Hello Benjamin,

we do not support secondary bootloader use cases in SEC tool yet, it is planned for future versions.

In order to find a suitable workaround for you I need more details:

1. do you have secure bootloader already provided by other 3rd party, or did you burn it yourself?
2. what secondary bootloader do you use? MCU Boot, or other?
3. what security do you plan to use?
4. if Signed who will validate the signature of the application?
   1. bootloader uses ROM?
   2. bootloader has its own mechanism independent on ROM (e.g. MCU Boot)

Regards,

Libor