AnsweredAssumed Answered

LPCXpresso54018 OM40003 secondary bootloader problem

Question asked by David Kaplan on Mar 11, 2019
Latest reply on May 23, 2019 by jamie lowrie

I am using the LPCXpresso54018 OM40003 board for development with MCUXpresso IDE v10.3.1 until our custom board arrives. I need to have a secondary bootloader in order to update the code in the field.

The secondary bootloader will be linked as a plain load image in order to run it from the ram after being loaded from the Quad External flash. Our main program will be linked as a XIP Quad flash program being offset by 0x100000 from the Quad flash start of 0x10000000. After reset the secondary bootloader will check if a new main program image has been stored in the SDCard and transfer it, if it is valid to the Quad flash offset. In any case, even if nothing is done, the secondary bootloader will check if a valid program is at the correct offset and jump there to run the main program.

I have checked that the process seems to work OK until the jump to the main program.

I have adapted several bootloaders for older NXP microcontrollers such as the LPC1768,LPC824,LPC1227 & etc.

Each one had its issues.


I changed the main program's linker origin to the offset.

 BOARD_FLASH (rx) : ORIGIN = 10100000, LENGTH = 0xF00000

I checked that the resulting bin file looked OK.


I looked at the lpcxpresso54018_flashloader SDK project to see how to jump.

I tried several things but all gave hard faults.


Is there some timing issues or something else that I must change before jumping to my main program which runs from the XIP Quad flash?


#define AMI_MAIN_PROG_ADDR             (FSL_FEATURE_SPIFI_START_ADDR+0x100000) // Leaves 1M for bootloader


Attached is my main file in which you can see the different things I tried.

I thought that the offset +4 is the reset vector.


If anyone could help, I would appreciate it.

Does anyone have a LPC54xxx bootloader example?

Like I wrote, I have a LPC1768 bootloader that works for a long time.