The subject line really describes the question, but here is some more commentary.
Here are a few items on things that I believe are true.
- The ARM reset vector is always at address 0x0000 0000. This means that addresses 0x0000 0000 - 0x0000 0003 contains a 32 pin encoded instruction that contains the assembly equivelent of “LDR pc,=Reset” where Reset is the address of the first line of code to be executed.
But wait - the LPC2xxx series of micros has a bootloader that is ALWAYS executed after reset. I know that the bootloader resides in the memory area 0x7FFF E000 - 7FFF FFFF, but I don’t know exactly where code execution in the bootloader should begin.
Interrupt Vector re-mapping. The datasheet for the LPC2101/02/03 briefly describes that re-mapping occurs, but leaves out some details like:
a. Does the entire interrupt vector table from the bootloader (including the extra 32 code bytes) get remapped by hardware immediately after the reset event ?
b. If the answer to “a” was yes, then how does the bootloader calculate the exception vector checksum for the user interrupt vectors, and compare it to the data stored at address 0x0000 0014 ? Are the user interrupt vectors copied somewhere before the bootloader vectors are re-mapped over them, or is there some sort of bank switching mechanism that the bootloader can use to flip back and forth between the two sets of data that reside at address 0x0000 0000 thru 0x0000 001F ?
It’s understandable that if the user data area is corrupt (ie the sum of the interrupt vectors aren’t 0), then the code will remain inside the bootloader area, and a complete set of vectors for the bootloader will need to reside in the interrupt vector area. However, if the checksum is correct, then the interrupt vectors must be flipped back to the user vectors, and the PC must be loaded with the “user” interrupt vector information at address 0x0000 0000.
This sequence of events is not completely described anywhere that I could find. Could some please provide some additional insight.
Thanks
gahelton:
a. Does the entire interrupt vector table from the bootloader (including the extra 32 code bytes) get remapped by hardware immediately after the reset event?
That's what NXP says (in section 2.2.2 of the User Manual).
gahelton:
b. If the answer to “a” was yes, then how does the bootloader calculate the exception vector checksum for the user interrupt vectors, and compare it to the data stored at address 0x0000 0014 ? Are the user interrupt vectors copied somewhere before the bootloader vectors are re-mapped over them, or is there some sort of bank switching mechanism that the bootloader can use to flip back and forth between the two sets of data that reside at address 0x0000 0000 thru 0x0000 001F ?
The User Manual says:
The boot loader code disables the overlaying of the interrupt vectors from the boot block, then checksums the interrupt vectors in sector 0 of the flash.
Memory mapping.
The User Manual says:
Quote:
The boot loader code disables the overlaying of the interrupt vectors from the boot block, then checksums the interrupt vectors in sector 0 of the flash.
Memory mapping.
I read that too. But here’s the problem. If the bootloader code disables overlaying of the interrupt vectors from the boot block, then how do you get to the bootloader code in the first place ? At a minimum, the entry point for the bootloader code must be overlaid onto the reset vector location at address 0x0000 0000. This has to be done in hardware as part of the reset sequence. Otherwise, you would never make it to boot code.
Still, a question remains about the checksum calculation. If the boot loader disables all vector overlaying except for the reset vector (which has to point somewhere into the boot loader code after reset), then how does the bootloader read the “user” reset vector information ?
It’s a subtle point, but unless there is another mechanism, then bootloader interrupt vectors overlaid onto the user interrupt vectors can’t be used for checksum calculation.
Thanks for the discussion.
gahelton:
If the bootloader code disables overlaying of the interrupt vectors from the boot block, then how do you get to the bootloader code in the first place?
Immediately after hardware reset, the memory relocation (overlaying) mode maps the bootloader interrupt vector area onto locations 0 and following. The ARM fetches from this remapped area, and the instruction it fetches is a branch into the bootloader (in the bootloader's native memory region). While the bootloader is running in flash-land, it switches the overlay mode to expose the user flash at locations 0 and following, and computes the checksum.
So you get to the bootloader code because the memory map is not disabled yet. The bootloader can turn this off and compute the checksum later.