LPCXpresso54018 OM40003 secondary bootloader problem

[kiryat8]

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.

Thanks

David

[jamie3]

Hi David, 

I am trying to achieve the exact same firmware update process on the 54018 to flash the Quad flash SpiFi from an update placed on a SD card from the SDIO card over FTP. 

Would you be willing to post the code from your bootloader, so i can try it?

Regards

Jamie

[kiryat8]

This morning upon Ricardo's request, I decided to use a simple SDK demo lpcxpresso54018_gpio_led_output as my main project and strip out some of the things concerning security specific to my secondary bootloader and try things.

First when changing the lpcxpresso54018_gpio_led_output project release memory.ld BOARD_FLASH offset, I noticed that I had somehow deleted the 0x prefix. Evidently this was my main problem along with messing around with the way I jumped to the main program because it did not work. The bootloader works fine linked as "plain load image". To change the bootloader to XIP, I would just have to change all of the functions used to write to the XIP to be run in the RAM, but I did not test this since there is no reason for the workaround,now.

I upload the two test projects.

1) The main project "lpcxpresso54018_gpio_led_output" just blinks the user leds when you press the user button on the LPCXpresso54018 board. I compiled it's release version as a XIP image with my offset to allow my bootloader in the lower memory.

2) My secondary bootloader program "Boot2", I ran in debug mode as a "plain load image".

The bootloader checks if the SDK's user button is pressed upon reset and then pops up a SDCard reader (Disk-on-key like) interface on USB0. You should copy the lpcxpresso54018_gpio_led_output.bin release file changed to 1.bin to the SDCard's root directory and then rest again the board.

If no user button is depressed upon reset, the bootloader looks in the SDCard root and checks if there is a file named 1.bin and then flashes it to the predefined offset. There is a file name and size define in the main.h that can be changed.

In any case, the bootloader will check if there is a valid image (basically) and will jump there otherwise it will jump loop flashing one led.

David

[nxf51211]

Hi David,

Checking your last answer, I see that you were able to work with the lpcxpresso54018_gpio_led_output project by fixing your issue with the 0x prefix. Concerning your second test project, I'm unable to understand what is the the issue you are dealing with right now; in other words, I would like to ask you if you could be more specific about the problems you're facing so I can help you with them.

NOTE:

Generally, your flash loader project has two tasks:

1. program application code to external spi flash.

2. boot application code at spi flash address.

To do these 2 tasks, your flash loader needs:

• 1 init spi flash internface, so your flash loader can use to  read and write the spi flash. You can refer to the SDK SPIFI example. The SPIFI interface supports spi flash program as well as XIP read, which means CPU can directly read spi flash data via AHB bus.

• This is simple, just set SPIFI into Memory Read mode and set SP, PC, and vector table into boot address (which will be at spi flash address (start @0x1000_0000)) and then, CPU will execute application at spi flash. 

I hope this last information can help you, and I'll be waiting for your reply.

Best regards,

Ricardo Delsordo.

[kiryat8]

Sorry that I was not clearer. Everything works and I have no problems currently.

The first project is the led blink that I used as a substitute for my main program in the test.

The second project is just my secondary bootlooder's basic code without any added security features.

Thanks

David

[kiryat8]

The ability to update our XIP Quad flash code over the air is a show stopper for this project.

If it is not possible then we will need to change our custom board's design.

Maybe the LPC54018 chip is the wrong choice.

If anyone has any ideas or could be of any help I'd appreciate it.

I was thinking that in my current secondary bootloader scenario, the bootloader is loaded from the QUAD flash and run from the ram (plain load image). Before I jump to my main application program, I may need to change the QUAD flash SPIFI interface. It is already in what I think is called read mode at that stage. I tried to do this but I always get a hard fault when I jump to my main program.

I tried another bootloader setup where the bootloader is a XIP program and I make the updating Quad Flash routines only, run from the ram. When I tried this out, without trying to update the Quad Flash, the jump to my main program gives a hard fault. I thought that since the program is running already XIP there would be no need to configure the SPIFI.

Could anyone provide me with a proper code snippet for the LPC54018 to jump to my main program compiled at a QUAD flash offset?

I am running out of ideas.

Help anyone!

[nxf51211]

Hi David,

I've noticed that you tried a different approach where the bootloader is an XIP program. Could you please share the project with this approach so I can reproduce your findings on my side?

Regards,

Ricardo Delsordo.