This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-M3 valid user code

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

Parents Reply Children
  • 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.

  • 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