Boot from Flash confusion

[brownd1970]

I'm going round in circles with how to move my development into  production with a simple process. I'm using the iMXRT1062 with IS25WP QSPI flash memory.

The BOOT_MODE[1] pin is pulled high, BOOT_MODE[0] pin is pulled low.

All BOOT_CONFIG pins are pulled low.

I have code built using Zephyr that runs without issue and I have used MCUBoot to create the bootloader with signed protection for loading the image.

If I load my combined HEX file into clean board using J-Link then nothing happens, but if I then connect using NXP-MCUBootUtility over UART then it jumps into life after connection - and then forever after it runs fine - but I've not deliberately changed any fuse settings.

Or, if I use the Secure Provisioning Tool to create the image from my bootloader HEX and my signed image HEX - it will then load incredibly slowly over UART.

My question is why can't I load my combined HEX file over J-Link and then it start running? My BOOT_MODE pins are set to run internally and my BOOT_CONFIG pins tell it to run from FLASH - don't they? I need to make it simple for production, and the simplest is to load a HEX file into a programmer.

Thanks

[brownd1970]

Yes, I'm starting to think that's exactly what the problem is. But how can I add that without having to use those tools?

As I said previously the SPT is incredibly slow over UART. Or can I use the image created from that and load it using SWD interface as the JLink does?

[Omar_Anguiano]

Yes, it is an option to use the generated image from SPT and load it through the debugger. 

BR,
Omar

[brownd1970]

I've used SPT to take my MCUboot+MainApp merged hex file and created an binary image on the "Build Image" tab. If I use the "Write Image" tab using UART interface then it loads in ~10mins and then works correctly.
But if I import that binary file into J-Flash then program using SWD then it loads in seconds but doesn't then run afterwards.

Loading the original hex file into J-Flash shows code has been added between 0x60000000 and 0x60020000 but then code afterwards is also different... I can also see this on the original MainApp binary image before it was converted to hex and before it was merged with MCUBoot.

[Omar_Anguiano · Accepted solution]

When you use the Secure Provisioning Tool (SPT) to build the image, it prepends the FCB and IVT to the binary so that the ROM bootloader can correctly initialize the QSPI flash and jump to your bootloader. This is why it works after UART flashing — the ROM sees the FCB and knows how to boot.

However, when you flash the same binary via J-Flash, it’s likely being written to the wrong address or without proper alignment, so the ROM bootloader doesn’t find the FCB at the expected location (0x60000000).

To make your production process work with J-Flash (SWD), you need to ensure:
The binary includes the FCB and IVT at the correct offset.
The binary is flashed to address 0x60000000, which is the start of the external QSPI flash.
The image layout is correct:

• 0x60000000: FCB
• 0x60001000: IVT + Bootloader
• 0x60002000 or later: Signed application image

On your image merged, you can make it to start at address 0x0 just like the SPT image, and when loading it on SWD, load it from 0x60000000.

BR,
Omar

[brownd1970]

OK, so my problem is now narrowed down to I need to understand how to use the Secure Provisioning Tool. Thanks

[Omar_Anguiano]

It is possible that your image does not have the necessary headers, the FCB is needed so the ROM bootloader knows how to communicate with the flash. MCUBootUtility and SPT add these headers.

BR,
Omar