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
  • 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.

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

Children
No data