This is quoted from datasheet: "The reserved Cortex-M3 exception vector location 7 (offset 0x 001C in the vector table) should contain the 2’s complement of the check-sum 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."
how am I supposed to calculate the checksum of 7 entries, the following is the first 7 entries of my code: 68020010 69010000 71010000 73010000 75010000 77010000 79010000
E6F4FFEF (flash magic calculates this checksum!!!)
HOW????????????????????????????????????????????????
The math and description are simple enough,
#include <stdio.h> int main(int argc, char **argv) { unsigned long vecs[]= { 0x10000268, 0x00000169, 0x00000171, 0x00000173, 0x00000175, 0x00000177, 0x00000179 }; int i; unsigned long sum; sum = 0; for(i=0; i<7; i++) sum += vecs[i]; printf("%08X\n", -sum); // expect 0xEFFFF4E6 return(1); }
Thanks for your answer, but I have two questions: 1- How did you extracted those numbers from the numbers I gave? 2- the sum of the numbers you have used is different than what flash magic calculates!
Best regards
Reverse the byte order (two-digit groups) and you get matching numbers.
Why am I supposed to do that? even if I do that, the checksum is still different and the program will not run!!!
o, actually it is true, the final result needs to be re-ordered in the same manner to get the original number which flash magic generates. But why?
Why do we do that? Is there an explanation?
Do you not understand endian ordering of byte vs half-word, and word values? The processor here is writes the LSB (Least Significant Byte) first.
This is some pretty fundamental stuff in the micro-processor realm.
www.cs.umd.edu/.../endian.html
Well I do know little endian and big endian concepts, I just didn't know they apply to checksum here. How did you this? Is there any document in NXP or somewhere to say so?
And thank you very much for your answers, I got my application running just fine!
The boot loader performs the task operating on 32-bit integers.
But look again at the numbers in your post:
68020010 69010000 71010000 73010000 75010000 77010000 79010000
As presented, the distance between the first and last value is 0x79010000 - 0x68020010 which is 0x10fefff0 or in decimal 285,147,120. That would represent a quite large program. And all but one of the vectors ends with 0000. This is an indication that your extraction of the vectors was not the actual 32-bit values, but that you have made use of an 8-bit hex dump - and you haven't taken into account if that hex dump had the values stored in little-endian or big-endian order.
So in short - your presented vectors that where garbled by the incorrect byte order in relation to their actual 32-bit values. If you had looked in your map file (you might have to turn on the map output generation), you would have noticed taht your "vectors" were not even close to the actual addresses of the target ISR code.
When you convert from individual bytes into 32-bit values, you must always process the four bytes in the same order that the processsor itself does.
You quoted the document in your first post, the description is clear enough, I'm not using the part and can figure it out. Your problem is a basic lack of understanding of how the processor represents 32-bit numbers in the memory space. The Vector Table is a list of 32-bit values. The algorithm adds the first 7 32-bit values in the table, and prints the negated (2's complement) value. The way the math works if you then sum the first 8 32-values they will sum to zero.
I've re-expressed the NXP description as C code, which should be pretty clear, the hurdle here was that you juggled the numbers up. I'm not sure NXP documents this as it's considered foundational knowledge. Some basic texts on microprocessors should cover it.
www.ntu.edu.sg/.../DataRepresentation.html
www.bottomupcs.com/chapter01.html www.bottomupcs.com/types.html
www.yolinux.com/.../Endian-Byte-Order.html
UM10360 LPC17xx User manual Rev. 2 — 19 August 2010 User manual
Chapter 34: Appendix: Cortex-M3 user guide
34.3.1.5 Data types The processor: • supports the following data types: – 32-bit words – 16-bit halfwords – 8-bit bytes • supports 64-bit data transfer instructions. • manages all data memory accesses as little-endian. See Section 34.3.2.1 for more information.
en.wikipedia.org/.../ARM_Cortex-M
Additional silicon options:[6][7] Data endianness: Little-endian or big-endian. Unlike legacy ARM cores, the Cortex-M is permanently fixed in silicon as one of these choices.
ARM deprecations The ARM architecture for ARM Cortex-M series removed some features from older legacy cores:[6][7] Endianness is chosen at silicon implementation in Cortex-M cores. Legacy cores allowed "on-the-fly" changing of the data endian mode.
Silicon options: Data endianness: little-endian or BE-8 big-endian.
(What is BE-8?)
I frequently discover that I am an idiot. I failed to understand BE-32 vs BE-8. It seems that it is not something I can understand within 3 minutes.
WOW!
Thanks a lot guys. There are many good answers here. Yes, I guess my problem is that I have never studied the architecture of ARM microcontrollers. I did not think that would be so important up until this point.But now I will take my time to know all about it.
Thanks again for your valuable help.
Regards