Forums

Problem with LPC2000 Flash Utility V2.2.3

Started by Martin Steppuhn January 10, 2006
Hello,

I have a Problem with the LPC2000 Flash Utility.
Uploading seems to be ok (Programm works and
the Flash Download looks ok)
but the "Compare Flash" Function always fails.
"File compare failed"

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 ?

Best regards,
Martin


An Engineer's Guide to the LPC2100 Series

In the "flash buffer" screen load your hex file and calculate the
"vector sum", save the hex file back to itself. Now the hex file will
match what goes in the part and the compare function will work. Rich

--- In lpc2000@lpc2..., "Martin Steppuhn"
<martin.steppuhn@h...> wrote:
>
> Hello,
>
> I have a Problem with the LPC2000 Flash Utility.
> Uploading seems to be ok (Programm works and
> the Flash Download looks ok)
> but the "Compare Flash" Function always fails.
> "File compare failed"
>
> 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 ?
>
> Best regards,
> Martin
>


Hi Richard,

now it works ! mni tnx !

Best regards,
Martin ----- Original Message -----
From: "Richard" <richas@rich...>
To: <lpc2000@lpc2...>
Sent: Tuesday, January 10, 2006 4:33 PM
Subject: [lpc2000] Re: Problem with LPC2000 Flash Utility V2.2.3 > In the "flash buffer" screen load your hex file and calculate the
> "vector sum", save the hex file back to itself. Now the hex file will
> match what goes in the part and the compare function will work. > Rich
>
> --- In lpc2000@lpc2..., "Martin Steppuhn"
> <martin.steppuhn@h...> wrote:
>>
>> Hello,
>>
>> I have a Problem with the LPC2000 Flash Utility.
>> Uploading seems to be ok (Programm works and
>> the Flash Download looks ok)
>> but the "Compare Flash" Function always fails.
>> "File compare failed"
>>
>> 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 ?
>>
>> Best regards,
>> Martin
> > Yahoo! Groups Links >



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