Secondary Bootloader hard fault exception (LPC824)

[brentsinger]

Hello All & happy New Year 2024.

I have an issue getting my bootloader to jump into a downloaded application. I'm hoping someone has had the same issue, and can help me solve it.

The SBL and process are based on AN11782, which is for my target LPC824, on the max demo board.

I've quickly built a blinky application to use as my application, which is loaded into Flash @ 0x2000:

1 of 1 ( 0) Writing sectors 8-13 at 0x00002000 with 5284 bytes

( 0) at 00002000: 0 bytes - 0/5284

( 19) at 00002000: 1024 bytes - 1024/5284

( 38) at 00002400: 1024 bytes - 2048/5284

( 58) at 00002800: 1024 bytes - 3072/5284

( 77) at 00002C00: 1024 bytes - 4096/5284

( 96) at 00003000: 1024 bytes - 5120/5284

(100) at 00003400: 1024 bytes - 6144/5284

The SBL I've rebuilt (also from blinky example in 824 sdk), since new SDK and MCUExpresso have issues with the older code in AN11782.

It has these key functions:

void execute_new_firmware(uint32_t addr)
{
	// This function copies interrupt vectors to 0x1000 0000 and remaps vectors to sram
	remap_vectors(addr);


	/* Jump to user application */
	JumpAddress = *(uint32_t*) (addr + 4);
	Jump_To_Application = (pFunction) (FIRMWARE_START + 4);
	__set_MSP(0x10002000);
	Jump_To_Application();
}

And remaps vectors:

void remap_vectors(uint32_t addr)
{
    uint32_t* src,*dst;
    int32_t size;

    src=(uint32_t*)addr;
    dst = (uint32_t*)FIRMWARE_START;
    size = VECT_SIZE;

    while(size > 0)
    {
        *dst++ = *src++;
        size -= 4;
    }

    // remap vectors to internal RAM
	LPC_SYSCON->SYSMEMREMAP = 0x1;
}

The app note wants the memory remapped to SRAM, and I'm not clear. Should the flash contents @0x2000 also be copied to 0x1000 0000 as well as the vectors in this case? This is not part of the application note, so I did not attempt.

My main function, which has the verification/signature pulled only because I haven't got to that just yet. My goal is just to jump to application first...

int main(void)
{
	uint8_t err;
	uint32_t fw_addr;

	/* Generic Initialization */
	SystemCoreClockUpdate(); 
    BOARD_InitBootPins();
    BOARD_InitBootClocks();

 
	while(1)
	{
		if(boot_chk_info.new_addr!=BLANK_VALUE_32B) {	//new firmware updated
			/* verify the new firmware */
			err = verify_fw();
			if(!err) {	//ready for new f/w execution
				if(RO_boot_addr.cur_addr != boot_chk_info.new_addr) {
//					fw_addr = boot_chk_info.new_addr;
					RW_boot_addr.new_addr = RO_boot_addr.cur_addr;
					RW_boot_addr.cur_addr = boot_chk_info.new_addr;
					/* NOTE: must firstly update f/w boot info then check info!!!*/
//					update_boot_info();
				}
//				update_chk_info();
			}
		}
		fw_addr = RO_boot_addr.cur_addr;

		/* execute firmware*/ 
		execute_new_firmware(fw_addr); // From original app note 
	}
}

The check_info.new_address is blank, so we skip to 'exectute_new_firmware(0x2000)' which is where I'm failing.

The code debug steps fine, up to calling "JumpToApplication()" whereupon I get a hard fault. My Registers before the final call:

The final call itself wants to move the PC to 0x1000 0004 - (FIRMWARE_START + 4)

Immediately after that final JumpToApplication() call I have this in Registers:

The PC @ 0x548, and NOT 0x1000 0004. Is that significant? 

Then when let to run freely, the debugger gives me a hard fault, and I'm not good at decoding these. Stack issue?? Please help.

I'm at a loss and I need some help to figure out why the App note doesn't work for me. My files are attached, hardware is just the LPC824max demo board + MCU-Link.

This is exposing my ignorance of how the boot process really works at a fine level; so please feel free to explain it to me like I'm a 12 year old. 

Payment in good karma and possibly beer if I am able one day Thanks in advance.

Brent.

[Alice_Yang]

Hello @brentsinger 

For secondary bootloader, recommend check below steps:

1) First confirm your application can work/debug well without bootloader, start address from 0x00.

2) Then change linker file make your application start from 0x2000, then debug it, confirm it works well, about how to debug, you can refer to :

https://community.nxp.com/t5/LPC-Microcontrollers/Lpc845-app-code-can-t-debug-after-bootloader/m-p/8... 

To do this, edit the launch configuration (by double clicking on the .launch file that will have been created in your project) and change the "reset handling" option to "SOFT".

3)Then download bootloader, debug, check whether can jump into application.

BTW,  AN11782 use LPC11U68 send new firmware to target board, what tool do you used? PC application?

BR

Alice

[brentsinger]

To make the reset vector offset happen in the binary all I had to do was:

a) change the flash region from 0x0 -> 0x2000, and reduce size to 0x6000.

b) clean and compile.

It is now 0x20e9 in the blinky binary. Upon download and execution, I get a successful jump to a new addresses in this order

--> 0x1000004 (reset vector in sram, which contains 0x000020e9, i.e. in the correct region of flash + thumb mode (right?))

--> hardfault hander @ 0x2548 with this trace:

And active faults:

Registers:

So does this suggest bootloader working, but the application is bad and causing a hard fault? 

[brentsinger]

I now think that the issue is the reset vector in the binary I've uploaded.

In the app example from AN11782 each of the two provided binaries for app have reset vectors: 0x50ED and 0x20ED which tracks to their intended flash address in the example.

My blinky app reset vect is 0xE9 and that's actually where the PC is jumping. So my linker script is the issue? That's not covered in the app note.

Also, the SP for both those example binaries is 0x2000, which tracks with call to set MSP @0x10002000. For my blinky it's 0x1FE0, so I imagine this is a linker script thing as well.

Does this all track?