How does the ROM bootloader find the entry point to my code?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How does the ROM bootloader find the entry point to my code?

Jump to solution
2,119 Views
robertpoor
Senior Contributor I

As per a previous question (How to get blhost to talk to ROM bootloader on the FRDM-KL27Z?), I've set up the flash_config area on my KL27Z code to call into the bootloader at startup.

After a short delay, if I have not invoked blhost, the ROM bootloader times out and calls into my application.

Since I have NOT created a Bootloader Configuration Area (BCA), how does the ROM bootloader discover the entry point for my application?  Is it hardwired to jump to 0x410?  (I'm asking because I plan to relocate my application to a non-standard place, and so I need to understand the linkage mechanism.)

Tags (1)
1 Solution
1,488 Views
robertpoor
Senior Contributor I

I guess I'm an expert at answering my own question: the ROM bootloader finds the entry point for my code at in the reset vector at address 0.  I was confused because I saw this in memory:

00000000: 00300020

00000004: 49060000

and forgot that this is stored as big-endian, so the correct interpretation is 

sp = 0x20003000

pc = 0x00000649

... and sure enough, it turns out that 0x0649 is the Reset_Handler for my code.

View solution in original post

2 Replies
1,488 Views
jay_heng
NXP Employee
NXP Employee

In addition, If you want to relocate your application to other place (for example: 0x1000), you should at least copy the first 8 bytes data of your application binary to 0x0 - 0x7, so CPU can get correct SP, PC after reset

1,489 Views
robertpoor
Senior Contributor I

I guess I'm an expert at answering my own question: the ROM bootloader finds the entry point for my code at in the reset vector at address 0.  I was confused because I saw this in memory:

00000000: 00300020

00000004: 49060000

and forgot that this is stored as big-endian, so the correct interpretation is 

sp = 0x20003000

pc = 0x00000649

... and sure enough, it turns out that 0x0649 is the Reset_Handler for my code.