Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 10 months ago.
Burning .hex file on LPC1768 flash memory using ISP
Dear friends,
hello. This is my first post on mbed. I have developed a C# program that accepts a .hex file, extracts raw information and converts it to UUencoded lines and then sends it to the LPC1768 MCU (ISP programming). I put the exact raw information on the microcontroller bu the program does not run properly.
I used flash magic to burn the same .hex file. everything is similar to what I have done, except that at address 0x0000010 there are some alteration made by flash magic (the last 4 bytes are different from raw data of the actual .hex file). I looked everywhere but could not find out what it has done. I would appreciate if somebody could help me.
with warm regards
1 Answer
8 years, 10 months ago.
Hello,
the following excerpt is from the LPC17xx user manual from chapter 32.3.1.1 "Criterion for Valid User Code":
Quote:
The reserved Cortex-M3 exception vector location 7 (offset 0x 001C in the vector table) should contain the 2’s complement of the checksum of table entries 0 through 6. This causes the checksum of the first 8 table entries to be 0. The boot loader code checksums the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is transferred to the user code.
The online compiler does this automatically for the generated bin-files, and also flash magic does it with hex files before or while transfering it to the microcontroller. So your script should also calculate the 32 Bit checksum of vectors 0 - 6 and write it to location 7. Otherwise the microcontroller doesn't recognise valid user code as present and starts the bootloader. I think, this is the same for all Cortex M microcontrollers from NXP (LPCxxxx), but don't know for the other manufacturers.
Best regards
Neni
Dear Neni,
Thanks a lot for your response. This is exactly what has been missing from my code. Only I do not quite understand the vector table and how to calculate check-sum for it and how to write it to the 7th location of this table. I would really appreciate if you could introduce a resource where I can find it.
Best regards
posted by 30 Jun 2015Dear Reza,
unfortunately i haven't more information on how it is done in detail. I only know it because of the mentioned quote in the NXP datasheets. Maybe there is an additional application note somewhere, which covers this issue, but i don't know. As far as i understand it from the quote you should sum up the first 7 32 Bit vectors (interpreting the vector value as a 32 Bit signed integer). The first 7 vectors should be located at addresses 0x00, 0x04, 0x08, 0x0C, 0x10, 0x14 and 0x18. From the calculated sum you take 2's complement and put the 32 Bit result into address 0x1C. This actually causes the sum of all 8 32 bit values to be 0.
I think you could try to deliberately change some of the first 7 32 bit values in your hex-file and then see what flash magic fills in in location 7 (address offset 0x1C) to deduce the checksum algorithm in detail.
Best regards
Neni
Do you mean the 4 bytes in address 0x010, 0x011, 0x012 and 0x012? (With more zeros in front)? And then do you mean the actual binary data in the hex file, or do you mean the ascii data in the hex file? Also which changes did flash magic make?
posted by Erik - 29 Jun 2015The third line in a .hex file.
for my hex file it looks like this:
:100010007501000077010000790100000000000078
raw information of this line: 75010000770100007901000000000000 what flash magic writes to flash: 750100007701000079010000E6F4FFEF
as you can see, the last 8 characters are different. (flash magic changes those zeros to E6F4FFEF and then sends it to MCU). This is the only place this happens. The other parts of .hex file remain unchanged.
posted by Reza Ghochkhani 29 Jun 2015