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.
A moderator can delete my previous post since it is no longer a problem. If I need to post a solution, I will.
I have a LPC2368 within my system that accepts a file to then program itself with.
I have two images -
a.) First image is the main image that always runs on the ARM. b.) Second image is a test image that blinks LEDs
Both images work as expected when programming them through the JTAG interface.
Within project B.), I have uVision 4 (and/or 5) generate a binary file as well as the .hex file. I do this because the binary representation is small than the hex representation (obviously).
Project A.) accepts the binary data of project B.) and stores the data bytes in an un-used portion of the ARM flash (starting at 0x00018000 because my memory map ends way prior to that).
I then have a function that runs out of RAM that then copies the data from the un-used portion of flash to the beginning of flash 0x00000000. I then reboot and project B.) doesn't run as it should.
I've done hex dumps of the memory regions being written and the data within these regions matches the original binary file (and the Intel hex file raw data) in both cases (un-used and in the beginning of flash).
I've also been reading about Criterion for Valid User Code and I'm thinking this is my problem.
The manual says the following :
Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014) should contain the 2’s complement of the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0. 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. If the signatures match then the execution control is transferred to the user code by loading the program counter with 0x0000 0000
If this is my problem, how do I prove it? How do I calculate the checksum of the remaining interrupt vectors? Where are they?
So the only interrupt vectors they are referring to is the ARM exception vectors, correct? i.e. Reset, Undefined Instruction, Software Interrupt (SWI), etc?
Below is an excerpt from the manual of the exception vectors. These are 16-bit vectors as well?
Table 11. ARM exception vector locations Address Exception 0x0000 0000 Reset 0x0000 0004 Undefined Instruction 0x0000 0008 Software Interrupt 0x0000 000C Prefetch Abort (instruction fetch memory fault) 0x0000 0010 Data Abort (data access memory fault) 0x0000 0014 Reserved Note: Identified as reserved in ARM documentation, this location is used by the Boot Loader as the Valid User Program key. This is described in detail in Section 29–3.1.1 . 0x0000 0018 IRQ 0x0000 001C FIQ
Is this what is causing the microprocessor to not boot up correctly? The binary file output I have is equivalent to the .hex file output with exception to the Intel Hex format headers preceeding the data. Shouldn't the output file have this data already in it?
>>Below is an excerpt from the manual of the exception vectors. These are 16-bit vectors as well?
4-bytes on my side of the planet is 32-bits
startup.s
; Exception Vectors ; Mapped to Address 0. ; Absolute addressing mode must be used. ; Dummy Handlers are implemented as infinite loops which can be modified. Vectors LDR PC,Reset_Addr ; 32-bit ARM relative load instruction LDR PC,Undef_Addr LDR PC,SWI_Addr LDR PC,PAbt_Addr LDR PC,DAbt_Addr NOP ; Reserved Vector LDR PC,IRQ_Addr LDR PC,FIQ_Addr ; Absolute addresses in literal table Reset_Addr DCD Reset_Handler Undef_Addr DCD Undef_Handler SWI_Addr DCD SWI_Handler PAbt_Addr DCD PAbt_Handler DAbt_Addr DCD DAbt_Handler DCD 0 ; Reserved Address IRQ_Addr DCD IRQ_Handler FIQ_Addr DCD FIQ_Handler Undef_Handler B Undef_Handler SWI_Handler B SWI_Handler PAbt_Handler B PAbt_Handler DAbt_Handler B DAbt_Handler IRQ_Handler B IRQ_Handler FIQ_Handler B FIQ_Handler
The linker does not sum the vectors for you, that is an NXP specific trait of their bootloader, not the ARM architecture itself. ARM doesn't used that vector location, NXP employer their own use for the location, 32-bit word at +20 (+0x14)
You would need to "sign" the image yourself in a post-link step.
*facepalm* - yes 32-bits, not 16-bit. My head breaks when switching between the two
It all makes sense now. I'm going to do a manual check of the this Valid User Program and see if that is what's broken.
Again, thanks a bunch.