Forums

IAP throwing Undefined Instruction on some units

Started by sig5534 February 23, 2006
CPU: LPC2104
Compiler: GCCARM

This is a really strange problem.  I am using IAP on some of my 
internal routines, my code was basically done for sometime now.  
Everything was working.  I built somemore proto boards and now a 
problem has shown up on 2 out of 11 boards.

When the IAP call executes to do a CopyRamToFlash, the CPU locks up 
going into the UIE vector (Undefined Instruction Exception). I ran a 
trace over and over again and the flash parameters are all setup 
right, but after the jump up into the high mem builtin IAP handler, 
it locks up the CPU at the UIE vector (0x38).  It never comes back 
from the IAP(CopyRamToFlash) call.

I can't understand this.  On 9 of the boards it works but on these 2 
it does not.  Same problem on both.  I have a 24MHz xtal and PLL set 
to 48Mhz.  I have tried calling the IAP() routine using either 24 or 
48 MHz but it makes no difference.  The built in IAP routine is going 
into the weeds, but only on some units.

Everything else on the PCBs is working normally, and the CPU is 
executing the rest of the code fine.  It is just that IAP() routine 
that is going nuts, and only on the CopyRamToFlash function.  The 
other calls like IAP erase sectors etc. are fine.

Other than the flashparameters, I do not see much else I can do to 
control the situation.  The IAP routine goes into the weeds on some 
LC2104 units but not on others.  Same code.  Really strange.  About 
the only thing I see left to do is change the CPUs.  Yet they take 
programming up the UART0 port.  Bizarre.

Anyone have any ideas on this?

Thanks,  Chris.
	

An Engineer's Guide to the LPC2100 Series

----- Original Message ----- 
From: "sig5534" <sig5534@sig5...>
To: <lpc2000@lpc2...>
Sent: Thursday, February 23, 2006 4:56 AM
Subject: [lpc2000] IAP throwing Undefined Instruction on some units
	> CPU: LPC2104
> Compiler: GCCARM
> 
> This is a really strange problem.  I am using IAP on some of my 
> internal routines, my code was basically done for sometime now.  
> Everything was working.  I built somemore proto boards and now a 
> problem has shown up on 2 out of 11 boards.
> 
> When the IAP call executes to do a CopyRamToFlash, the CPU locks up 
> going into the UIE vector (Undefined Instruction Exception). I ran a 
> trace over and over again and the flash parameters are all setup 
> right, but after the jump up into the high mem builtin IAP handler, 
> it locks up the CPU at the UIE vector (0x38).  It never comes back 
> from the IAP(CopyRamToFlash) call.
> 
> I can't understand this.  On 9 of the boards it works but on these 2 
> it does not.  Same problem on both.  I have a 24MHz xtal and PLL set 
> to 48Mhz.  I have tried calling the IAP() routine using either 24 or 
> 48 MHz but it makes no difference.  The built in IAP routine is going 
> into the weeds, but only on some units.
> 
> Everything else on the PCBs is working normally, and the CPU is 
> executing the rest of the code fine.  It is just that IAP() routine 
> that is going nuts, and only on the CopyRamToFlash function.  The 
> other calls like IAP erase sectors etc. are fine.
> 
> Other than the flashparameters, I do not see much else I can do to 
> control the situation.  The IAP routine goes into the weeds on some 
> LC2104 units but not on others.  Same code.  Really strange.  About 
> the only thing I see left to do is change the CPUs.  Yet they take 
> programming up the UART0 port.  Bizarre.
> 
> Anyone have any ideas on this?

What silicon revision?

Leon

> What silicon revision?
> Leon

It says 1.3  I guess that is the problem.  I see now that there is a 
BIG errata info on this whole problem.  I just downloaded the stuff on 
the bootloader update to 1.52.  This sure sounds like the problem I am 
seeing.  I'll try it tomorrow.  In fact I did further testing and found 
that the same chip/board would sometimes pass and then fail IAP calls.  
So this is indeed a flaky problem.

From what I see on updating the boot loader, it appears to be a bit of 
a procedure.  Not a fun prospect for updating 100 units we have 
arriving for the first production run.

I also see in the Errata a bunch of info on the SPI problems I saw last 
year.  I guess I know now I wasn't crazy after all.  Philips had quite 
a few bugs in these critters.

Thanks,  Chris.
	
I think your crystal is faster than most of us use, so you might
be in uncharted territory.

Is it possible that you're giving the IAP call the wrong value for
the system clock frequency? The time of the flash write might be
process-dependent (and temperature and supply-voltage) so it
might vary from chip to chip. If the processor returns before
the flash is ready, who knows what instruction will be fetched.

Param3 should be 24000 or 48000 because it is in kHz.
Try boosting it by 20% to see if it is an extreme process corner.

(It is possible that such numbers are outside the range Philips
tested in their IAP delay routines. But the data sheet says
it should cope with up to 25000 kHz).

Another thing I would try is a longer delay between
"prepare for write" and "copy ram to flash".
ISP programming is likely to have a long delay between commands.

Hope this helps you get these chips working,
Danish
	
I think the other guys hit the problem.  Philips has bugs in the old 1.3
version boot loader.  I will try updating the boot loaders tomorrow to 1.52. 
The info in the errata PDF is exactly what I am seeing, and it happens at higher
clk rates which is exactly what I have.  Actually quite a few bugs in these
parts. I've run into other bugs last year that I now see documented in the PDF
of Nov-2005.

Thanks,  Chris.
  ----- Original Message ----- 
  From: Danish Ali 
  To: lpc2000@lpc2... 
  Sent: Thursday, February 23, 2006 12:58 AM
  Subject: [lpc2000] Re: IAP throwing Undefined Instruction on some units
	  I think your crystal is faster than most of us use, so you might
  be in uncharted territory.

  Is it possible that you're giving the IAP call the wrong value for
  the system clock frequency? The time of the flash write might be
  process-dependent (and temperature and supply-voltage) so it
  might vary from chip to chip. If the processor returns before
  the flash is ready, who knows what instruction will be fetched.

  Param3 should be 24000 or 48000 because it is in kHz.
  Try boosting it by 20% to see if it is an extreme process corner.

  (It is possible that such numbers are outside the range Philips
  tested in their IAP delay routines. But the data sheet says
  it should cope with up to 25000 kHz).

  Another thing I would try is a longer delay between
  "prepare for write" and "copy ram to flash".
  ISP programming is likely to have a long delay between commands.

  Hope this helps you get these chips working,
  Danish
	  SPONSORED LINKS Microcontrollers  Microprocessor  Intel microprocessors  
        Pic microcontrollers
	------
  YAHOO! GROUPS LINKS 

    a..
	------
	
	
If you are curious.  That was the problem.  All of the boards are working
now.

Chris.

  ----- Original Message ----- 
  From: sig5534@sig5... 
  To: lpc2000@lpc2... 
  Sent: Thursday, February 23, 2006 1:05 AM
  Subject: Re: [lpc2000] Re: IAP throwing Undefined Instruction on some units
	  I think the other guys hit the problem.  Philips has bugs in the old 1.3
version boot loader.  I will try updating the boot loaders tomorrow to 1.52. 
The info in the errata PDF is exactly what I am seeing, and it happens at higher
clk rates which is exactly what I have.  Actually quite a few bugs in these
parts. I've run into other bugs last year that I now see documented in the PDF
of Nov-2005.

  Thanks,  Chris.
    ----- Original Message ----- 
    From: Danish Ali 
    To: lpc2000@lpc2... 
    Sent: Thursday, February 23, 2006 12:58 AM
    Subject: [lpc2000] Re: IAP throwing Undefined Instruction on some units
	    I think your crystal is faster than most of us use, so you might
    be in uncharted territory.

    Is it possible that you're giving the IAP call the wrong value for
    the system clock frequency? The time of the flash write might be
    process-dependent (and temperature and supply-voltage) so it
    might vary from chip to chip. If the processor returns before
    the flash is ready, who knows what instruction will be fetched.

    Param3 should be 24000 or 48000 because it is in kHz.
    Try boosting it by 20% to see if it is an extreme process corner.

    (It is possible that such numbers are outside the range Philips
    tested in their IAP delay routines. But the data sheet says
    it should cope with up to 25000 kHz).

    Another thing I would try is a longer delay between
    "prepare for write" and "copy ram to flash".
    ISP programming is likely to have a long delay between commands.

    Hope this helps you get these chips working,
    Danish
	    SPONSORED LINKS Microcontrollers  Microprocessor  Intel microprocessors  
          Pic microcontrollers
	  ------
    YAHOO! GROUPS LINKS 

      a..
	  ------
	  
	  SPONSORED LINKS Microcontrollers  Microprocessor  Intel microprocessors  
        Pic microcontrollers
	------
  YAHOO! GROUPS LINKS 

    a..
	------