Lpc2000

Robert,

> Anyone know of a website with a LPC2000 checksum for dummies type page?! ;~)

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