Yahoo Groups archive
Thread
2005-01-07 by Leighton Rowe
Is it true that Phillips ISP does the checksum calculation before programming the vector code into flash? I notice the .hex files that I'm making (using IAR's software) doesn't contain the calculated checksum (0x14)for the vector code. It's usually filled with 0's (without the fill option). Is there's a way for me to generate the vector checksum in the 0x14 space of the hex file?
2005-01-07 by Robert Adsett
At 06:53 PM 1/7/05 +0000, you wrote:
>Is it true that Phillips ISP does the checksum calculation before
>programming the vector code into flash?
Yes, as do both the other serial ISP programs I am aware of.
>Is there's a way for me to generate the vector checksum in the 0x14
>space of the hex file?
Well, you could read it into Philps SW and have calculate the checksum and
write in back out again. I think that works anyway. I'm not sure I see
the point though.
Robert
" 'Freedom' has no meaning of itself. There are always restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, III2005-01-07 by Leighton Rowe
> Well, you could read it into Philps SW and have calculate the checksum and > write in back out again. I think that works anyway. I'm not sure I see > the point though. Well the IAP updater that I'm working on reads the hex file and reprograms the lpc with the new code. If u look at the hex file example... :1000000018F09FE5FEFFFFEAFEFFFFEAFEFFFFEAB2 :10001000FEFFFFEAFFFFFFFFF0FF1FE500F09FE597 <---0x0014 is "FFFFFFFF" :10002000A48C000028950000FFFFFFFFFFFFFFFFEB ...my concern is that the vector checksum in the hex file isn't generated. I'd rather have the IAP updater do a vector check (before programming the reset block) instead of just calculating & storing the vector sum. The latter seems to assume that there are valid jump commands in the reset block. Leighton
2005-01-07 by Robert Adsett
At 07:46 PM 1/7/05 +0000, you wrote:
> > Well, you could read it into Philps SW and have calculate the
>checksum and
> > write in back out again. I think that works anyway. I'm not sure
>I see
> > the point though.
>
>Well the IAP updater that I'm working on reads the hex file and
>reprograms the lpc with the new code.
>
>If u look at the hex file example...
>:1000000018F09FE5FEFFFFEAFEFFFFEAFEFFFFEAB2
>:10001000FEFFFFEAFFFFFFFFF0FF1FE500F09FE597 <---0x0014 is "FFFFFFFF"
>:10002000A48C000028950000FFFFFFFFFFFFFFFFEB
>
>...my concern is that the vector checksum in the hex file isn't
>generated. I'd rather have the IAP updater do a vector check (before
>programming the reset block) instead of just calculating & storing
>the vector sum. The latter seems to assume that there are valid jump
>commands in the reset block.
OK, but a valid checksum won't be any assurance that the jumps are
valid. That'll just mean that something may have calculated the
checksum. The tool (whatever its is) that does the checksum calculation
could have been fed an invalid file as easily as the updater.
If you want to only use verified files then I'd think about encapsulating
them with a whole file check (CRC, MD5 or something similarly robust). You
could even use some sort of cryptographic checksum with your own key so
that it was difficult to forge.
I'm thinking that the validity check (and checksum calculation come to
that) should be done by the download program not the micro (for that
matter, that's the way the ISP programs do it).
Robert
" 'Freedom' has no meaning of itself. There are always restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, III2005-01-07 by Mark Butcher
Hi Leighton As you are now aware the Philips ISP generate the check sum during download. However there may be some more issues here to consider. 1. The checksum is used by the boot to check whether there is user code in the FLASH. If the check is not good the boot code stays in ISP mode thus allowing an update. The value must be correct otherwise the (user) code will never start. 2. The validity of the check sum says nothing about the validity of the program. A bad program can crash as soon as it starts and the boot software is stuck. It will always start the bad code and this will always crash - to get out of this loop the only way is to hold the ISP pin input low on reset. 3. Also the download of a good software is not fool proof. If the download is interrupted before it is complete you effectively get situation 2. 4. An improvement of the Philips ISP loader would be to load the application coded first and the vector tables with check sum (validity) as very last job. This would avoid 2 occuring when interrupting a download in 99,99% of the casees (exception is interrupting as the vactor table exactly then when it is being programmed...) Cheers Mark Butcher www.mjbc.ch PS I have an encoded signature over the user program which is verified before the application allows itself to start (security requirement). Important to note is that this technique requires about 32k of the code space just for this feature - is it worth it in most applications? Code can be used from OpenSSL project... --- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> wrote: > > Is it true that Phillips ISP does the checksum calculation before > programming the vector code into flash? > > I notice the .hex files that I'm making (using IAR's software) > doesn't contain the calculated checksum (0x14)for the vector code. > It's usually filled with 0's (without the fill option). > > Is there's a way for me to generate the vector checksum in the 0x14 > space of the hex file?
2005-01-13 by rob@usbmicro.com
> Is it true that Phillips ISP does the checksum calculation before
> programming the vector code into flash?
> I notice the .hex files that I'm making (using IAR's software)
> doesn't contain the calculated checksum (0x14)for the vector code.
> It's usually filled with 0's (without the fill option).
> Is there's a way for me to generate the vector checksum in the 0x14
> space of the hex file?
Leighton,
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...>2005-01-13 by Richard
You can load your HEX file in the the flash utility, generate the checksum (Vector calc button in the flash screen) and save the HEX file back. Richard --- In lpc2000@yahoogroups.com, rob@u... wrote: > > > Is it true that Phillips ISP does the checksum calculation before > > programming the vector code into flash? > > > I notice the .hex files that I'm making (using IAR's software) > > doesn't contain the calculated checksum (0x14)for the vector code. > > It's usually filled with 0's (without the fill option). > > > Is there's a way for me to generate the vector checksum in the 0x14 > > space of the hex file? > > Leighton, > > 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...>
2005-01-13 by Leighton Rowe
> > 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 > > The Hard Coded way...not bad at all. > You can load your HEX file in the the flash utility, generate the > checksum (Vector calc button in the flash screen) and save the HEX > file back. > > Richard That's pretty close to what I'm currently doing before updating the firmware using IAP calls (not the ISP utility) during code execution. Both would work for me. Thanks. Leighton
2005-01-14 by rob@usbmicro.com
>> > 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 >> > > The Hard Coded way...not bad at all. I'm sure that you understand this, but for those that don't, let me mention that 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. [Insomnia is no fun...] -Rob
>> You can load your HEX file in the the flash utility, generate the >> checksum (Vector calc button in the flash screen) and save the HEX >> file back. >> >> Richard > That's pretty close to what I'm currently doing before updating the > firmware using IAP calls (not the ISP utility) during code execution. > Both would work for me. Thanks. > Leighton > Yahoo! Groups Links