Lpc2000

I was testing the CRC16 checksum routine from Technical Note 91733 
from IAR and it worked for all my program except the region between 
0x00 and 0x1F (where the interrupt vectors lie). 

I verifyed the bytes from the hex with ones that I was reading when 
I notice something weird:

:020000040000FA

:10 0000 00 18F09FE5FFFFFFFFFFFFFFFFFFFFFFFF 70
:10 0010 00 FFFFFFFFFFFFFFFF18F09FE518F09FE5 D0

:10 0020 00 40000000FFFFFFFFFFFFFFFFFFFFFFFF 9C
:10 0030 00 FFFFFFFFFFFFFFFFC8400200E8400200 94


As you can see in the segment of a hex file above the three verctors 
reset, IRQ and FIQ are the same 18 F0 9F E5!!!!

The should be pointing to the program start point, IRQ and FIQ ISRs

I belive it is some trace program placed by the compiler, but I 
already disable all debug options ant the vectors continue the same.

Some one knows:
1) What is this?
2) What it is pointing to?
3) Why?
4) If it is some trace from the compiler, how I remove it?

Hello,

On Wednesday 11 January 2006 16:55, carlosahsilva wrote:
> :020000040000FA
> :
> :10 0000 00 18F09FE5FFFFFFFFFFFFFFFFFFFFFFFF 70
> :10 0010 00 FFFFFFFFFFFFFFFF18F09FE518F09FE5 D0
> :
> :10 0020 00 40000000FFFFFFFFFFFFFFFFFFFFFFFF 9C
> :10 0030 00 FFFFFFFFFFFFFFFFC8400200E8400200 94
>
> As you can see in the segment of a hex file above the three verctors
> reset, IRQ and FIQ are the same 18 F0 9F E5!!!!
>
> The should be pointing to the program start point, IRQ and FIQ ISRs
>
> I belive it is some trace program placed by the compiler, but I
> already disable all debug options ant the vectors continue the same.
>
> Some one knows:
> 1) What is this?
> 2) What it is pointing to?
> 3) Why?
> 4) If it is some trace from the compiler, how I remove it?

e59ff018        ldr     pc, [pc, #24]

All your vectors jump to the address stored at the vector + 0x20.
I'm a bit unsure where this is pointing:
> :10 0020 00 40000000FFFFFFFFFFFFFFFFFFFFFFFF 9C
I guess that should be 0x40000000, but the LPCs are little-endian, aren't 
they?

Regards,

Dominic

Yes, my project is little-endian.

but I am also clueless about the destination

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> 
wrote:
>
> Hello,
> 
> On Wednesday 11 January 2006 16:55, carlosahsilva wrote:
> > :020000040000FA
> > :
> > :10 0000 00 18F09FE5FFFFFFFFFFFFFFFFFFFFFFFF 70
> > :10 0010 00 FFFFFFFFFFFFFFFF18F09FE518F09FE5 D0
> > :
> > :10 0020 00 40000000FFFFFFFFFFFFFFFFFFFFFFFF 9C
> > :10 0030 00 FFFFFFFFFFFFFFFFC8400200E8400200 94
> >
> > As you can see in the segment of a hex file above the three 
verctors
> > reset, IRQ and FIQ are the same 18 F0 9F E5!!!!
> >
> > The should be pointing to the program start point, IRQ and FIQ 
ISRs
> >
> > I belive it is some trace program placed by the compiler, but I
> > already disable all debug options ant the vectors continue the 
same.
> >
> > Some one knows:
> > 1) What is this?
> > 2) What it is pointing to?
> > 3) Why?
> > 4) If it is some trace from the compiler, how I remove it?
> 
> e59ff018        ldr     pc, [pc, #24]
> 
> All your vectors jump to the address stored at the vector + 0x20.
> I'm a bit unsure where this is pointing:
> > :10 0020 00 40000000FFFFFFFFFFFFFFFFFFFFFFFF 9C
> I guess that should be 0x40000000, but the LPCs are little-endian, 
aren't 

> they?
> 
> Regards,
> 
> Dominic
>

carlosahsilva wrote:

>I was testing the CRC16 checksum routine from Technical Note 91733 
>from IAR and it worked for all my program except the region between 
>0x00 and 0x1F (where the interrupt vectors lie). 
>  
>
Reason for this is most likely because the vector at address 0x14 
changed. This vector is ununsed in the ARM and contains a checksum for 
the vector table (this is calculated by the download tools before 
downloading the code). Reason is that the lpc21xx will only start the 
code in flash if the checksum of the table computes - to be sure that 
only real code is executed.

>As you can see in the segment of a hex file above the three verctors 
>reset, IRQ and FIQ are the same 18 F0 9F E5!!!!
>  
>
As Dominic writes this is: e59ff018 ldr pc, [pc, #24]
This is an ARM instruction that will load PC with the content of PC + 0x24

If you'd like to know more about this, get the datasheets from the ARM 
website and start playing with an ARMulator (GDB includes one that is 
mostly functional).

Rob

Hi! I have head the manual and discovered that the reset jump is 
placed by the start up code:

__program_start
		ldr	pc,[pc,#24]	; Absolute jump can reach 4 
GByte
;		ldr	b,?cstartup	; Relative branch allows 
remap, limited to 32 MByte
                ; Vectors can be enabled by removing the comments 
below or by
                ; using #pragma vector from C code.
		org	0x04
;		ldr	pc,[pc,#24]	; Branch to undef_handler
		org	0x08
;		ldr	pc,[pc,#24]	; Branch to swi_handler
		org	0x0c
;		ldr	pc,[pc,#24]	; Branch to prefetch_handler
		org	0x10
;		ldr	pc,[pc,#24]	; Branch to data_handler
		org	0x18
;		ldr	pc,[pc,#24]	; Branch to irq_handler
		org	0x1c
;		ldr	pc,[pc,#24]	; Branch to fiq_handler

As you can see the first is enable by this code. The irq handler is 
and FIQ handler are commented, but they were inserted by the linker 
by the pragmas:

#pragma vector=0x18
__irq __arm void IRQ_ISR_Handler (void)

and

#pragma vector=0x1c
__fiq __arm void FIQ_ISR_Handler (void)

This makes Xlink to place this calls in code and redirect the a jump 
located in the first 32 bytes of RAM (where will be my actual ISR 
routines jumpers). 

All is OK the only thing that is not OK is why the XLINK does not 
correctly computates the CRC when I choose the range:

-HFFFF
-J2,crc16,,__FirmCheckSum,CHECKSUM,1,0=(CODE)0x00-ROMEND

it only works properly if I place as below:

-HFFFF
-J2,crc16,,__FirmCheckSum,CHECKSUM,1,0=(CODE)0x20-ROMEND

Apparently the the range from 0x00 to 0x1F is not properly processed 
by XLINK in the automatic CRC calculation.


--- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:
>
> carlosahsilva wrote:
> 
> >I was testing the CRC16 checksum routine from Technical Note 
91733 
> >from IAR and it worked for all my program except the region 
between 
> >0x00 and 0x1F (where the interrupt vectors lie). 
> >  
> >
> Reason for this is most likely because the vector at address 0x14 
> changed. This vector is ununsed in the ARM and contains a checksum 
for 
> the vector table (this is calculated by the download tools before 
> downloading the code). Reason is that the lpc21xx will only start 
the 
> code in flash if the checksum of the table computes - to be sure 
that 
> only real code is executed.
> 
> >As you can see in the segment of a hex file above the three 
verctors 
> >reset, IRQ and FIQ are the same 18 F0 9F E5!!!!
> >  
> >
> As Dominic writes this is: e59ff018 ldr pc, [pc, #24]
> This is an ARM instruction that will load PC with the content of 
PC + 0x24
> 
> If you'd like to know more about this, get the datasheets from the 
ARM 
> website and start playing with an ARMulator (GDB includes one that 
is 

> mostly functional).
> 
> Rob
>