Lpc2000

Has anyone used built-in In-Application Programming functions 
successfully in any of those LPC's??

I'm having problems erasing sectors and wonder if someone would help 
me figure out what am i missing.

Thanx in advance,
Gonzalo

--- In lpc2000@yahoogroups.com, givc@y... wrote:
> Has anyone used built-in In-Application Programming functions 
> successfully in any of those LPC's??
> 
> I'm having problems erasing sectors and wonder if someone would 
help 
> me figure out what am i missing.

Hi Gonzalo,

I am also having problems with the LPC2114.  It would consistently 
hang in "Copy RAM to Flash" and "Erase sectors", and when running at 
cclk=60MHz, it would generate a Prefetch Abort after 29 seconds (58 
seconds when running at cclk=30MHz).

After reading
http://groups.yahoo.com/group/lpc2000/message/2472
I contacted Promax, and after a while I learned that my chip might 
also be affected by the firmware bug, and that the problem mostly 
happens with cclk > ~11 MHz.  As a workaround, until I get new chips, 
I now disable the PLL around the two IAP calls, running them at 
cclk=Fosc=10MHz.  It now seems to work.  This of course also messes 
up the peripherals since pclk is also changed, but since all 
interrupts must be disabled (my interrupt handlers are in flash), not 
much can work during IAP anyway.

Karl Olsen

> I am also having problems with the LPC2114.  It would consistently 
> hang in "Copy RAM to Flash" and "Erase sectors", and when running 
at 
> cclk=60MHz, it would generate a Prefetch Abort after 29 seconds 
(58 
> seconds when running at cclk=30MHz).

Are you using the prepare sector command before u erase/write them? 
What area in flash are u trying to write over? Just curious. 

> I contacted Promax, and after a while I learned that my chip might 
> also be affected by the firmware bug, and that the problem mostly 
> happens with cclk > ~11 MHz.  As a workaround, until I get new 
chips, 
> I now disable the PLL around the two IAP calls, running them at 
> cclk=Fosc=10MHz.  It now seems to work.  This of course also 
messes 
> up the peripherals since pclk is also changed, but since all 
> interrupts must be disabled (my interrupt handlers are in flash), 
not 
> much can work during IAP anyway.

As long as u call the IAP function passing in the frequency value of 
the physical crystal, I think PLLs shouldn't matter...enabled or 
disabled. I have my PLL enabled running @60Mhz now on a 12MHz Xtal, 
and I can call IAP to write flash without trouble using 12Mhz as the 
frequency value. 

Interrupt events can mess the IAP process. Hopefully that's the only 
firmware bug to worry about. 

Leighton

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> > I am also having problems with the LPC2114.  It would 
consistently 
> > hang in "Copy RAM to Flash" and "Erase sectors", and when running 
> at 
> > cclk=60MHz, it would generate a Prefetch Abort after 29 seconds 
> (58 
> > seconds when running at cclk=30MHz).
> 
> Are you using the prepare sector command before u erase/write them? 
> What area in flash are u trying to write over? Just curious. 

I am using the prepare sectors command.  Without it, I get the 
expected error codes.
I am using sector 14 (1C000h-1DFFFh).

 
> > I contacted Promax, and after a while I learned that my chip 
might 
> > also be affected by the firmware bug, and that the problem mostly 
> > happens with cclk > ~11 MHz.  As a workaround, until I get new 
> chips, 
> > I now disable the PLL around the two IAP calls, running them at 
> > cclk=Fosc=10MHz.  It now seems to work.  This of course also 
> messes 
> > up the peripherals since pclk is also changed, but since all 
> > interrupts must be disabled (my interrupt handlers are in flash), 
> not 
> > much can work during IAP anyway.
> 
> As long as u call the IAP function passing in the frequency value 
of 
> the physical crystal, I think PLLs shouldn't matter...enabled or 
> disabled. I have my PLL enabled running @60Mhz now on a 12MHz Xtal, 
> and I can call IAP to write flash without trouble using 12Mhz as 
the 
> frequency value. 

The manual states that you should pass the cclk frequency, and not 
Fosc.  I would also have thought that the use of the PLL shouldn't 
matter as long as you passed the right frequency value, but my 
experiments show otherwise.  Try disabling the PLL.


> Interrupt events can mess the IAP process. Hopefully that's the 
only 
> firmware bug to worry about. 

It is not.  And I wouldn't call it a firmware (IAP) bug if the 
processor crashed because an un-disabled interrupt came during an IAP 
call and tried to execute out of flash.

Karl Olsen

Thanx for the info Karl!!  I think I'd been in that message some 
days ago, but I guess I was too tired that I didn't paid enough 
atention to the bug.

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> Are you using the prepare sector command before u erase/write 
them? 
> What area in flash are u trying to write over? Just curious. 
> 

My problem is exactly the same as Karl. And I do prepare the sectors
(2nd to 14th) before any erase/flash command. Just as Karl, 
yesterday figured out that the problem was the CCLK frequency. 
Disabling the PLL and running at 12Mhz enables me to erase sectors, 
but still, sometimes doesn't return from the command.

>must be disabled (my interrupt handlers are in flash), 
> not 
> > much can work during IAP anyway.
> 
> As long as u call the IAP function passing in the frequency value 
of 
> the physical crystal, I think PLLs shouldn't matter...enabled or 
> disabled. I have my PLL enabled running @60Mhz now on a 12MHz 
Xtal, 
> and I can call IAP to write flash without trouble using 12Mhz as 
the 
> frequency value. 
> 

I thought that was my error, but I make sure that I was passing the 
correct frequency.

I'm working with a LPC2119 (BootCode Ver 1.6) Even though the 
message 2472 only says that parts LPC2106 and LPC2129 have the bug, 
I think that the LPC2119 has it too (It's pretty much the same thing 
as the LPC2129).

Who should I write to, in order to make sure whether the part I'm 
using has the IAP bug or not??

I took a long look at your reply and the message reference on the 
bug. Honestly I haven't experienced this bug before. Are all 
lpc2114/19/29 chips affected?

> The manual states that you should pass the cclk frequency, and not 
> Fosc.  I would also have thought that the use of the PLL shouldn't 
> matter as long as you passed the right frequency value, but my 
> experiments show otherwise.  Try disabling the PLL.

Yeah, I see it in the manual. It's very wierd that I still got good 
writes & erases when I passed in frequencies other than cclk with 
PLL enabled. Sorry to be a thorn though but can someone explain why 
and/or how PLLs can affect IAP alternate writes & erases?

Thanks

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> I took a long look at your reply and the message reference on the 
> bug. Honestly I haven't experienced this bug before. Are all 
> lpc2114/19/29 chips affected?

Apparently not.  Contact Philips with the complete chip markings, 
boot loader ID and part ID.  I did through my distributor (Promax).

To philips_apps: Could you _please_ update the errata with 
information about these flash/firmware issues?


> Yeah, I see it in the manual. It's very wierd that I still got good 
> writes & erases when I passed in frequencies other than cclk with 
> PLL enabled. Sorry to be a thorn though but can someone explain why 
> and/or how PLLs can affect IAP alternate writes & erases?

Only Philips knows the internals of the flash code.  philips_apps?

Karl Olsen

At 08:36 PM 7/14/04 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...>
>wrote:
> > Yeah, I see it in the manual. It's very wierd that I still got good
> > writes & erases when I passed in frequencies other than cclk with
> > PLL enabled. Sorry to be a thorn though but can someone explain why
> > and/or how PLLs can affect IAP alternate writes & erases?
>
>Only Philips knows the internals of the flash code.  philips_apps?

True, but a pretty intelligent guess would be that it uses the frequency 
for timing programming pulses.  You can program a lot of memories with 
wrong pulse timings and have them work but the long term reliability will 
be suspect.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III