We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I am tasked with porting my LPC2478 bootloader to a LPC1768. I have read the documentation and I'm fully aware of the differences in boot behavior but I just can't get it right - here is the problem: Once my bootloader jumps to applicaton, the processor treats (as far as I could tell) the beginning of the vector table as code - not fetching the initial SP and the reset vector (=execution start address) followed by a jump to that address. It goes on, until an STM instruction is executed to internal flash - after which it is all over. This is only my second day really working with an LPC1768 - can you clarify what I'm doing wrong?
Fetching these 2 values, followed by a jump, is done after the processor leaves reset. I understand that. But I cannot really reset the chip - I need to start the application. What can I do?
It looks like the jump to application needs to happen before the bootloader leaves its reset handler...?
OK, I got it. You just need to program the stack pointer and the initial PC for the application by hand, just like the processor does after reset.
Whew, what a relief.
I don't have any experience on Cortex-M3, but maybe: The Definitive Guide to the ARM Cortex-M3
Joseph Yiu
Since the address 0x0 should be boot code, usually it will either be Flash memory or ROM devices, and the value cannot be changed at run time. However, the vector table can be relocated to other memory locations in the Code or RAM region where the RAM is so that we can change the handlers during run time. This is done by setting a register in the NVIC called the vector table offset register (address 0xE000ED08). The address offset should be aligned to the vector table size, extended to the power of 2. For example, if there are 32 IRQ inputs, the total number of exceptions will be 32 + 16 (system exceptions) = 48. Extending it to the power of 2 makes it 64. Multiplying it by 4 makes it 256 (0x100). Therefore, the vector table offset can be programmed as 0x0, 0x100, 0x200, and so on. The vector table offset register contains the items shown in Table 7.7.
John,
One major difference between an ARM7 device and a Cortex-M3 is the content of the vector table: when you jump to application in an ARM7, you can expect code inside the vector table, so you can jump to its beginning and know you are correct. The vector table of a Cortex-M3 needs to be dereferenced in order to retrieve the entry point to the application.
The Cortex-M3 is designed to allow 100% C code - you can implement all of the startup code in C.
And there are no special ISR prologes/epiloges which means that there is no need for any interrupt keyword for an ISR either.