Lpc2000

Dear all,

I am writing this just to prevent you writing off a chip or two in the
future.

If I run the following code - I can NEVER either:

1. Download code via JTAG (Under Rowley 1.3 this manifestes itself as
a 'cannot stop CPU' error)

2. Download code via the Philip Flash utility 2.2.0

Here it is (***** PLEASE DO NOT TRY THIS UNLESS YOU LIKE UNSOLDERING
144 PIN LPC2214s FROM YOUR DEV BOARD ****)

/* Configure External INT 0 as a high level interrupt */

void init_eint0 (void)

{
    unsigned char extpolar;

   
    VICIntEnClear = (1 << 14);        /* Make sure tha EINT0 interrupt
is disabled */

    IO0DIR &= ~(1 << 16);             /* P0.16 = input */
    PINSEL1 &= ~3;                    /* P0.16 pin = EINT0 */
    PINSEL1 |=  1;

    VICIntSelect &= ~(1 << 14);       /* EINT0 is an IRQ interrupt */
    VICVectCntl2 = (0x20 | 14);       /* Use slot 2 for EINT0 interrupt */
    VICVectAddr2 = (unsigned long) &eint0_isr; /* Set the address of
ISR for slot 2 */

    EXTINT = ((EXTINT & 0x0f) | 0x08); /* Clear any pending EINT0
Interrupt */

   
/* EINT0 polarity = high level */

    extpolar = EXTPOLAR & 0x0f;
    extpolar |= 1;
    EXTPOLAR  = extpolar;

/* EINT0 = Level sensitive - not edge */   

    extmode = EXTMODE & 0x0f;         
    extmode &= ~1;
    EXTMODE  = extmode; 
    VICIntEnable = (1 << 14);         /* Enable EINT0 interrupt */
}


I wrote this code before seeing the following in the Philips LPC2214
Errata sheet:

EXTINT.1 Corruption of VPBDIV via EXTPOLAR or EXTMODE
Introduction: The VPBDIV register controls the rate of the VPB clock
in relation to the processor clock.
EXTPOLAR and EXTMODE determine the operating parameters of the
external interrupts.
Problem: A write to either the external interrupt polarity register
(EXTPOLAR) or the external interrupt mode
register (EXTMODE) will corrupt the VPBDIV register. A read of either
EXTPOLAR or EXTMODE
will be corrupted BY the VPBDIV register. If VPBDIV is "1" or "2"
prior to any write to EXTPOLAR
or EXTMODE, the CPU will hang up on the write to EXTPOLAR or EXTMODE.
work-around: If VPBDIV is non-zero, write all zeroes to VPBDIV before
reading or writing EXTMODE or
EXTPOLAR, then write the proper value back to VPBDIV. In most
applications this is a known and
fixed value, but if there is a possibility of dynamic changes in
VPBDIV, software will need to read
VPBDIV, write zero to VPBDIV, read or write EXTMODE and/or EXTPOLAR,
and then rewrite the
value previously read from VPBDIV.

However, the errata sheet doesn't mention a statement like 'You must
clear VPBDIV first before writin to EXTMODE / EXPOLAR or it will
bugger up your chip for life!'

Has anyone else found this? - We went through 3 chips before realising
it was related to the above errata note...but why? It must be that
after a reset, the boot loader runs the 'offending firmware' which
locks up the CPU...but there is no way over being able to JTAG in and
'over blow' the 'offending firmware' evr agin....hmmm...


Jane

janehighland wrote:
> Has anyone else found this? - We went through 3 chips before realising
> it was related to the above errata note...but why? It must be that
> after a reset, the boot loader runs the 'offending firmware' which
> locks up the CPU...but there is no way over being able to JTAG in and
> 'over blow' the 'offending firmware' evr agin....hmmm...

That doesn't explain why you can't get into the bootloader via RS232- 
the state of the bootloader pin is checked before any user code is executed.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

--- Alex Holden <alex@...> wrote: 

---------------------------------
janehighland wrote:
> Has anyone else found this? - We went through 3
chips before realising
> it was related to the above errata note...but why?
It must be that
> after a reset, the boot loader runs the 'offending
firmware' which
> locks up the CPU...but there is no way over being
able to JTAG in and
> 'over blow' the 'offending firmware' evr
agin....hmmm...

That doesn't explain why you can't get into the
bootloader via RS232- 
the state of the bootloader pin is checked before any
user code is executed.


Yes I know. I couldn't fathom it out either...BUT I
got the same result on three boards. It was
conclusive. After swapping a CPU for a new one and
implementing the  fix in the errata sheet, everything
was OK. I have asked Philips (via a distributor) to
try the code out for themselveves.

Jane

-- 
------------ Alex Holden - http://www.alexholden.net/
------------
If it doesn't work, you're not hitting it with a big
enough hammer


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/
 
   To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
 
   Your use of Yahoo! Groups is subject to the Yahoo!
Terms of Service.
 


	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Hi Jane,

I have had a similar problem, but my code was:

VPBDIV = 0;
VPBDIV = 0;
EXTMODE = 0x05;             // EINT0 and EINT2 edge-sensitive
EXTPOLAR = 0x01;            // EINT0 rising-edge, EINT2 falling-edge
VPBDIV = 1;
VPBDIV = 1;

I have had different errors on diferent CPUs.
I think it is an activation of Code read protection.
Flash erase with Philips Flash utility fixed this problem
(I mean after it I can access my CPU).



--- In lpc2000@yahoogroups.com, "janehighland" <janehighland@y...> wrote:
> 
> Dear all,
> 
> I am writing this just to prevent you writing off a chip or two in the
> future.
> 
> If I run the following code - I can NEVER either:
> 
> 1. Download code via JTAG (Under Rowley 1.3 this manifestes itself as
> a 'cannot stop CPU' error)
> 
> 2. Download code via the Philip Flash utility 2.2.0
> 
> Here it is (***** PLEASE DO NOT TRY THIS UNLESS YOU LIKE UNSOLDERING
> 144 PIN LPC2214s FROM YOUR DEV BOARD ****)
> 
> /* Configure External INT 0 as a high level interrupt */
> 
> void init_eint0 (void)
> 
> {
>     unsigned char extpolar;
> 
>    
>     VICIntEnClear = (1 << 14);        /* Make sure tha EINT0 interrupt
> is disabled */
> 
>     IO0DIR &= ~(1 << 16);             /* P0.16 = input */
>     PINSEL1 &= ~3;                    /* P0.16 pin = EINT0 */
>     PINSEL1 |=  1;
> 
>     VICIntSelect &= ~(1 << 14);       /* EINT0 is an IRQ interrupt */
>     VICVectCntl2 = (0x20 | 14);       /* Use slot 2 for EINT0
interrupt */

>     VICVectAddr2 = (unsigned long) &eint0_isr; /* Set the address of
> ISR for slot 2 */
> 
>     EXTINT = ((EXTINT & 0x0f) | 0x08); /* Clear any pending EINT0
> Interrupt */
> 
>    
> /* EINT0 polarity = high level */
> 
>     extpolar = EXTPOLAR & 0x0f;
>     extpolar |= 1;
>     EXTPOLAR  = extpolar;
> 
> /* EINT0 = Level sensitive - not edge */   
> 
>     extmode = EXTMODE & 0x0f;         
>     extmode &= ~1;
>     EXTMODE  = extmode; 
>     VICIntEnable = (1 << 14);         /* Enable EINT0 interrupt */
> }
> 
> 
> I wrote this code before seeing the following in the Philips LPC2214
> Errata sheet:
> 
> EXTINT.1 Corruption of VPBDIV via EXTPOLAR or EXTMODE
> Introduction: The VPBDIV register controls the rate of the VPB clock
> in relation to the processor clock.
> EXTPOLAR and EXTMODE determine the operating parameters of the
> external interrupts.
> Problem: A write to either the external interrupt polarity register
> (EXTPOLAR) or the external interrupt mode
> register (EXTMODE) will corrupt the VPBDIV register. A read of either
> EXTPOLAR or EXTMODE
> will be corrupted BY the VPBDIV register. If VPBDIV is "1" or "2"
> prior to any write to EXTPOLAR
> or EXTMODE, the CPU will hang up on the write to EXTPOLAR or EXTMODE.
> work-around: If VPBDIV is non-zero, write all zeroes to VPBDIV before
> reading or writing EXTMODE or
> EXTPOLAR, then write the proper value back to VPBDIV. In most
> applications this is a known and
> fixed value, but if there is a possibility of dynamic changes in
> VPBDIV, software will need to read
> VPBDIV, write zero to VPBDIV, read or write EXTMODE and/or EXTPOLAR,
> and then rewrite the
> value previously read from VPBDIV.
> 
> However, the errata sheet doesn't mention a statement like 'You must
> clear VPBDIV first before writin to EXTMODE / EXPOLAR or it will
> bugger up your chip for life!'
> 
> Has anyone else found this? - We went through 3 chips before realising
> it was related to the above errata note...but why? It must be that
> after a reset, the boot loader runs the 'offending firmware' which
> locks up the CPU...but there is no way over being able to JTAG in and
> 'over blow' the 'offending firmware' evr agin....hmmm...
> 
> 
> Jane