The checksum?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> -----Original Message-----
> From: Robert Wood [mailto:robert.wood@robe...]
> Sent: 16 October 2005 18:53
> To: lpc2000@lpc2...
> Subject: [lpc2000] Processor won't run without JTAG interface
>
> Hi folks,
>
> I have some code in an LPC2194 which runs fine with the JTAG
> interface plugged in (using Crossworks if that's relevant).
> However, if I unplug the wiggler and power cycle the board,
> it will not run. P0.14 and P1.20 are pulled high, and RTCK is
> pulled low.
>
> Are there any common problems with this issue I should look out for?
>
> Cheers,
>
> Rob
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> Fair play? Video games influencing
> politics. Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dN_tlB/TM
> --------------------------
> ------~-
> Yahoo! Groups Links
>
>
Re: Processor won't run without JTAG interface
Started by ●October 16, 2005
Reply by ●October 16, 20052005-10-16
Hi folks,
I have some code in an LPC2194 which runs fine with the JTAG interface
plugged in (using Crossworks if that's relevant). However, if I unplug
the wiggler and power cycle the board, it will not run. P0.14 and P1.20
are pulled high, and RTCK is pulled low.
Are there any common problems with this issue I should look out for?
Cheers,
Rob
I have some code in an LPC2194 which runs fine with the JTAG interface
plugged in (using Crossworks if that's relevant). However, if I unplug
the wiggler and power cycle the board, it will not run. P0.14 and P1.20
are pulled high, and RTCK is pulled low.
Are there any common problems with this issue I should look out for?
Cheers,
Rob
Reply by ●October 16, 20052005-10-16
Hi Robert,
> >> The checksum? <<
>
> Hmmm, yes. That was it.
Nothing like online support on a Sunday eveinging...
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> >> The checksum? <<
>
> Hmmm, yes. That was it.
Nothing like online support on a Sunday eveinging...
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
Reply by ●October 16, 20052005-10-16
>> The checksum? <<
Hmmm, yes. That was it. I went back to one I'd commented out for some
reason. I don't understand this checksum business or why it's there. The
datasheet makes no sense to me.
Anyone know of a website with a LPC2000 checksum for dummies type page?! ;~)
Hmmm, yes. That was it. I went back to one I'd commented out for some
reason. I don't understand this checksum business or why it's there. The
datasheet makes no sense to me.
Anyone know of a website with a LPC2000 checksum for dummies type page?! ;~)
Reply by ●October 16, 20052005-10-16
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
> 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
