Martin,
> It looks like a problem with the vector table
> checksum at 0x00000014 ?!
> Hexfile not includes location 0x00000014 but
> Bootloader flashes this location. Is this the
> reason for fail ? I could not believe that tis is
> normal ?
(I posted this once quite a while ago to address a similar issue.)
You can get your source to take care of this checksum generation for
you. This is what I do.
The vector table for the processor (The first 32 bytes of memory)
normally has branches to the routines. Since routine addresses change
as code is changed, the checksum changes.
I created a table of seven addresses located immediately after the
vector table. These seven addresses are the start addresses for reset
and the interrupts. The branch instructions of the interrupt vector
table were replaced with a load PC instruction pointing to the
appropriate address.
The hex file will then have the checksum. My startup code below:
@---
@ Interrupt vectors
@---
intvect:
LDR pc, startaddr
LDR pc, undefinstaddr
LDR pc, softintaddr
LDR pc, preabortaddr
LDR pc, dataabortaddr
.word 0xb8a06f60
LDR pc, interruptaddr
LDR pc, fastintaddr
startaddr:
.word start
undefinstaddr:
.word undefined_instruction_routine
softintaddr:
.word software_interrupt_routine
preabortaddr:
.word prefetch_abort_routine
dataabortaddr:
.word data_abort_routine
interruptaddr:
.word interrupt_routine
fastintaddr:
.word fast_interrupt_routine
@---
@ Start up code
@---
start:
<code...
The checksum is done over the first 8 integers (32 bit integers) of
flash memory excluding the area where the checksum is stored. That
is, in the assembly code above, the stuff between the label
"intvect:" and the label "startaddr".
Although the location for start and all of the routines may change as
code is developed, all of those changes happen after the label
"startaddr:" (as resolved by the linker).
The net result is that the first 32 bytes (address 0000 to 001F)
will always contain the same values, and thus the checksum (two's
compliment sum) will also remain the same. The hex file will have
these first two lines:
:10 0000 00 18F09FE5 18F09FE5 18F09FE5 18F09FE5 C0
:10 0010 00 18F09FE5 606FA0B8 14F09FE5 14F09FE5 1D
(I added spaces to make it easier to understand.)
You can see the ".word 0xb8a06f60" in the hex file which is the
two's compliment sum of the other integers. (Note the byte order is
reversed.) 0xb8a06f60 doesn't need to change, even when the routines
move.
So no need for any external program to do the calculation each time
that the source is compiled.
I anticipate using a loader other than the Philips utility, so I
wanted to resolve the checksum calculation without needing to use the
Philips utility. This way the hex file has the checksum.
-Rob
www.USBmicro.com
