Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: Interrupt vector 18 F0 9F E5 - What the heck is this? LPC2136/38

2006-01-12 by carlosahsilva

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
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.