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?
>>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