Lpc2000

> 1/  The coding of the flash programming algorithm in the boot loader
> unreliable because: a) it depends on wait loops rather than polling the
> flash controller status register; and b) it requires clock frequency to be
> passed as a run-time argument.

I believe jasoorah is not the first person on this group to have found
that wrong crystal freq's in the isp application can create dead
parts, or at least bad data in flash.  I recall several posts long
before the CRP debate, though I'm too lazy to search for them.  I seem
to recal they involved 2104/5/6 parts, so there is a possibility that
this has been repaired in later parts like the 2148 and 2101/2/3.

I, for one, had origonally assumed the presence of a crystal-freq in
the isp app was just for setting baud-rate dividers appropriately,
though in hindsight, it's obvious that that's needed in the device,
not the pc.  This news makes one very cautious, and I don't hesitate
to say that a bootloader requiring a human to type in the crystal freq
to program memory is worthy of being disparaged, in my opinion.  Which
is not to say that I've seen conclusive proof that this is the case,
either from this group, or on my own.  This is one that seems to me
philips could lay to rest easialy - if the crystal freq is not used
for timing memory programming, they can say so.  I don't see why the
snip of code uilizing the xtal freq couldn't be published.

For the record: I have a 2148 board with a 12MHz xtal, and 2106 &
2103's with a 14.xxxMHz, and I'm always forgetting to change the
crystal freq in the isp app.  Aside from giving me heart-failure every
time I do it, I have not yet trashed a part, but then I'd say I've
been through less than 50 isp cycles with all my boards put together,
and those two frequencies are only 17% apart as well.

Steve

At 09:30 AM 2/22/2006 -0700, Steve Franks wrote:
> > 1/  The coding of the flash programming algorithm in the boot loader
> > unreliable because: a) it depends on wait loops rather than polling the
> > flash controller status register; and b) it requires clock frequency to be
> > passed as a run-time argument.
>
>I, for one, had origonally assumed the presence of a crystal-freq in
>the isp app was just for setting baud-rate dividers appropriately,
>though in hindsight, it's obvious that that's needed in the device,
>not the pc.  This news makes one very cautious, and I don't hesitate
>to say that a bootloader requiring a human to type in the crystal freq
>to program memory is worthy of being disparaged, in my opinion.  Which

How else do you propose they determine the frequency in order to set 
internal timing dependent parameters?

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
http://www.aeolusdevelopment.com/

>
> How else do you propose they determine the frequency in order to set
> internal timing dependent parameters?
>
> Robert
>

Call me naive, but I've never experienced another uC that had obvious
'internal timing dependant parameters'.  Neither Avr, Msp, or Pic ask
for a crystal freq in their ISP applications; that's why I initially
assumed it was for setting the baudrate, and I don't discount that it
still may be.

The main point of my email was 1) to point out that previous
references to bootloader problems existed before jaysoorah, brendan
and company got everyone riled with the CRP debate, and that 2) I was
doing something that had a high probablility of breaking the
bootloader, but that it had *not* done so as yet on my hardware.  In
short, I'm mining for technical answers, and they do seem to be
'burried' in the SNR.  I don't agree with the antagonistic fashion in
which this debate has been executed, nor do I have strong evidence
that there *is* or *is not* a problem.  I have not had any replies
which appeared to further my technical understanding of the issue, so
you can consider my input closed for this thread, effective
immediately.

Steve

Hi, 

> > How else do you propose they determine the frequency in order to set
> > internal timing dependent parameters?
> >
> > Robert
> 
> Call me naive, but I've never experienced another uC that had obvious
> 'internal timing dependant parameters'.  Neither Avr, Msp, or Pic ask
> for a crystal freq in their ISP applications; that's why I initially
> assumed it was for setting the baudrate, and I don't discount that it
> still may be.

Actually, the MSP430 *does* require that you program up the flash timing
generator in order ro correctly clock the flash state machine--it's just
you don't see it in the BSL.  The MSP430 bootstrap loader runs off the
MSP430's internal DCO at approximately 1MHz from reset so it can program
the FTG with a known oscillator frequency.  The key here is a *known
oscillator frequency*.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

At 04:20 PM 2/22/2006 -0700, Steve Franks wrote:
> >
> > How else do you propose they determine the frequency in order to set
> > internal timing dependent parameters?
> >
> > Robert
> >
>
>Call me naive, but I've never experienced another uC that had obvious
>'internal timing dependant parameters'.  Neither Avr, Msp, or Pic ask
>for a crystal freq in their ISP applications; that's why I initially
>assumed it was for setting the baudrate, and I don't discount that it
>still may be.

You've just run across a narrower range of micros.  The ST10F168 with it's 
STEAK ISP algorithm takes clock speed as a parameter to its commands and 
includes this note in its documentation

"Note That big difference (1,5 time) between this
value and the real CPU period may affect
the flash reliability."

I don't see it as a big deal in any case, wrap it up in a batch or script, 
heck make an icon driven script on your desktop if you insist of using a 
mouse and you're done. One minute of prep and you don't risk setting it 
wrong again.

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
http://www.aeolusdevelopment.com/

Hello,

For what it's worth, the TMS320F28xx and F240x DSP devices with flash
also require that you pass the clock frequency and PLL setting to the flash
algorithm.

Jerry
Signum Systems
www.signum.com
==============================================
     26 YEARS OF EMULATION SYSTEMS DESIGN: 
  8051, ARM, OMAP, 80186, 80196 and TMS320 DSPs
==============================================


----- Original Message ----- 

From: "Paul Curtis" <plc@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, February 22, 2006 3:59 PM
Subject: RE: [lpc2000] re: bootloader


> Hi, 
> 
> > > How else do you propose they determine the frequency in order to set
> > > internal timing dependent parameters?
> > >
> > > Robert
> > 
> > Call me naive, but I've never experienced another uC that had obvious
> > 'internal timing dependant parameters'.  Neither Avr, Msp, or Pic ask
> > for a crystal freq in their ISP applications; that's why I initially
> > assumed it was for setting the baudrate, and I don't discount that it
> > still may be.
> 
> Actually, the MSP430 *does* require that you program up the flash timing
> generator in order ro correctly clock the flash state machine--it's just
> you don't see it in the BSL.  The MSP430 bootstrap loader runs off the
> MSP430's internal DCO at approximately 1MHz from reset so it can program
> the FTG with a known oscillator frequency.  The key here is a *known
> oscillator frequency*.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
>

Steve,

there is a simple reason why most 8-bit micros do not require the
frequency in the programming call. They have internal oscillators with
fixed frequencies. These fixed frequencies are used for Flash timing. 
The LPC2000 devices and for that matter most ARM micros do not have
these oscillators (yet). As we see more and more analog peripherals
being integrated like in the 8-bit devices, it is probably only a
matter of time when many ARM micros have an internal oscillator as well. 

fwiw

Bob

--- In lpc2000@yahoogroups.com, "Steve Franks" <stevefranks@...> wrote:

>
> >
> > How else do you propose they determine the frequency in order to set
> > internal timing dependent parameters?
> >
> > Robert
> >
> 
> Call me naive, but I've never experienced another uC that had obvious
> 'internal timing dependant parameters'.  Neither Avr, Msp, or Pic ask
> for a crystal freq in their ISP applications; that's why I initially
> assumed it was for setting the baudrate, and I don't discount that it
> still may be.
> 
> The main point of my email was 1) to point out that previous
> references to bootloader problems existed before jaysoorah, brendan
> and company got everyone riled with the CRP debate, and that 2) I was
> doing something that had a high probablility of breaking the
> bootloader, but that it had *not* done so as yet on my hardware.  In
> short, I'm mining for technical answers, and they do seem to be
> 'burried' in the SNR.  I don't agree with the antagonistic fashion in
> which this debate has been executed, nor do I have strong evidence
> that there *is* or *is not* a problem.  I have not had any replies
> which appeared to further my technical understanding of the issue, so
> you can consider my input closed for this thread, effective
> immediately.
> 
> Steve
>