Lpc2000

I have a problem with my programme, i want to make my UART work, but
without the FIFOs, is there anyway to get a receive interrupt when
only one character has been recieved, or do I have to wait for the
FIFO to be full?

In the case of using TIMEOUT, how do I fix that TIMEOUT value?

Thanks

Quoting bacalaoencebollao <bacalaoencebollao@...>:
> I have a problem with my programme, i want to make my UART work, but
> without the FIFOs, is there anyway to get a receive interrupt when
> only one character has been recieved, or do I have to wait for the
> FIFO to be full?

The FIFO must be turned on.

However, you will recieve an interrupt on a single character.  It will just be
delayed (by 1.5 character time IIRC).  That allows the buffer to fill for a
stream of characters but interrupt on pauses in the stream if there are
characters waiting in the FIFO.

Robert

Robert Adsett wrote:

>Quoting bacalaoencebollao <bacalaoencebollao@...>:
>  
>
>>I have a problem with my programme, i want to make my UART work, but
>>without the FIFOs, is there anyway to get a receive interrupt when
>>only one character has been recieved, or do I have to wait for the
>>FIFO to be full?
>>    
>>
>
>The FIFO must be turned on.
>
>However, you will recieve an interrupt on a single character.  It will just be
>delayed (by 1.5 character time IIRC).  That allows the buffer to fill for a
>stream of characters but interrupt on pauses in the stream if there are
>characters waiting in the FIFO.
>
>  
>
I run interrupt driven I/O on UART0 without the FIFO turned on...  Seems 
to work fine for me on the LPC2138 and LPC2106.

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

At 04:47 PM 4/28/2006 -0400, Tom Walsh wrote:
>Robert Adsett wrote:
> >Quoting bacalaoencebollao <bacalaoencebollao@...>:
> >>I have a problem with my programme, i want to make my UART work, but
> >>without the FIFOs, is there anyway to get a receive interrupt when
> >>only one character has been recieved, or do I have to wait for the
> >>FIFO to be full?
> >>
> >>
> >
> >The FIFO must be turned on.
> >
> >However, you will recieve an interrupt on a single character.  It will 
> just be
> >delayed (by 1.5 character time IIRC).  That allows the buffer to fill for a
> >stream of characters but interrupt on pauses in the stream if there are
> >characters waiting in the FIFO.
> >
> >
> >
>I run interrupt driven I/O on UART0 without the FIFO turned on...  Seems
>to work fine for me on the LPC2138 and LPC2106.

It's a nasty little bug Tom, I was running w/o the FIFOs on and ran into a 
problem that I eventually 'fixed' by only reading the IIR once per 
interrupt.  Before that under an echo load the serial interrupts would 
occasionally stop.  (My test was a simple echo test and it would take 
several hours to fail at full load)  Note that these tests were on a 2106.

Jacob Oursland recently reported the bug reappearing in his code.  This 
time turning on the FIFO fixed the problem   Given that the user manual has 
a one line note stating that the FIFO must be turned on (I missed it when I 
went through it too) I suspect it's been nailed this time but I leave open 
the possibility it may re-occur.  It really stinks of an underlying HW race 
condition.

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/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> 

> It really stinks of an underlying HW race 
> condition.

I think the kind hardware *and* software (in the supplied Bootloader)
problems on the LPC Family is without precedent.

The hardware problems -- have a look at LPC2292 errata: VPBDIV has to
be read twice; it gets corrupted when external interrupt mode is set;
MAM timing has to be set even if it is not used; ADC will miss
conversions; SPI interrupt flag gets unintentionally cleared; TIMER
will miss interrupts under some conditions; UART generates spurious
interrupts in the receive channel; and the link register contents
incorrect when abort occurs in THUMB mode after certain instruction
sequence.  This is just the list of problems I had to deal with, and
there are more in the Errata.

The software problems -- implementation of boot loader ISP mode pin
function clashes with DCD requirements when UART0 is used in slave
mode; boot loader external bus select implementation clashes with use
of analog inputs, how it attempts to provide security, how it
interfaces with the outside world.

Never have I see so much discussion about hardware solutions to
software problems as much as I have in this forum.

I find it intimidating to entertain the notion of hardware fixes
software problem.

Jaya

At 12:25 AM 4/29/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...>
>
> > It really stinks of an underlying HW race
> > condition.
>
>I think the kind hardware *and* software (in the supplied Bootloader)
>problems on the LPC Family is without precedent.

I've seen worse, and I've heard that the 4 bit micros used in are much 
worse.  At least all the problems are in the peripherals and most have SW 
workarounds.  Race conditions seem to have been a particular blind spot for 
some reason though, most of the HW problems seem to lead back to some sort 
of race.

>The software problems -- implementation of boot loader ISP mode pin
>function clashes with DCD requirements when UART0 is used in slave
>mode; boot loader external bus select implementation clashes with use
>of analog inputs, how it attempts to provide security, how it
>interfaces with the outside world.

DCD/ISP is a design issue not a SW or HW bug.  Personally I don't think the 
ISP pin should have bee multiplexed at all but other micros do similar 
things with similar consequences if the data sheets are not read carefully 
and the startup conditions fully considered.

>Never have I see so much discussion about hardware solutions to
>software problems as much as I have in this forum.

Um, hardware solutions to software problems, what hardware solutions to 
what software problems?  I haven't seen any discussed.  The closest I've 
seen was a use of an or gate for allowing DCD to be used (a single sot23 
for an extra input pin, not a bad tradeoff). I'd consider that a hardware 
solution to a design problem, possibly a hardware solution to a hardware 
problem.  The user manual should be more open about the dangers of DCD 
though to warn off the unwary.

Despite the fact I'd like to see Philips being a little faster about 
acknowledging bugs they do at least make the errata easily available.

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/

At 09:51 PM 4/28/2006 -0400, Robert Adsett wrote:
>At 12:25 AM 4/29/2006 +0000, jayasooriah wrote:
> >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...>
> >
> > > It really stinks of an underlying HW race
> > > condition.
> >
> >I think the kind hardware *and* software (in the supplied Bootloader)
> >problems on the LPC Family is without precedent.
>
>I've seen worse, and I've heard that the 4 bit micros used in are much
>worse.

Mutter, used in high volume toys, mutter mutter

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/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> At 12:25 AM 4/29/2006 +0000, jayasooriah wrote:
> >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@>
> >
> > > It really stinks of an underlying HW race
> > > condition.--- In lpc2000@yahoogroups.com, Robert Adsett
<subscriptions@...> wrote:
> >I think the kind hardware *and* software (in the supplied Bootloader)
> >problems on the LPC Family is without precedent.
> 
> I've seen worse, and I've heard that the 4 bit micros used in are much 
> worse.  At least all the problems are in the peripherals and most
have SW 
> workarounds.  Race conditions seem to have been a particular blind
spot for 
> some reason though, most of the HW problems seem to lead back to
some sort 
> of race.

I like to know if you think any other ARM licensee is worse.

> DCD/ISP is a design issue not a SW or HW bug.

I agree it is design issue.  I call it a defect in that the design
because it did not take into account of the kind requirements one user
had -- where the UART0 is operated in slave mode.

To fix this defect, one can change the software (in boot loader) or
add hardware to work around.  The extent to which people had discuss
about hardware options was what I referred to as intimidating.

> Personally I don't think the 
> ISP pin should have bee multiplexed at all but other micros do similar 
> things with similar consequences if the data sheets are not read
carefully 
> and the startup conditions fully considered.

One big difference I found in other micros whose feature the LPC seems
to emulate.  They have these features designed more completely and
have it implemented in hardware.

In the case of LPC, the boot loader firmware attempts to mimic these
features, and they have chosen the deferred design approach to leave
this in firmware for future updates.

Boot loader should be simple -- just to provide bare minimum to gain
control when there is no firmware, not to provide virtual flash
abstractions, external bus configuration or software protection.

The mistake IMO Philips did in incorporating these functions into a
boot loader is that they had to make it upgradeable (given things go
wrong as we have seen) and in the process, ended up with the situation
where it is possible to lock out the hardware by software.  I know of
no other system that does.  OTPs are different of course by design.

Having to condition analog input in order to use watchdog is a serious
design defect.  The fix is simple if it were done in the bootloader.
It is the obvious solution.  Saves having endless discussion on how to
solve this defect with yet another gate or chip.

> Despite the fact I'd like to see Philips being a little faster about 
> acknowledging bugs they do at least make the errata easily available.

Everyone does these days and through the web.  Gone are the days when
I had to chase suppliers to get the technical contact, and then have
to explain why I need the latest errata sheet for the engineering
sample I working on.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> I like to know if you think any other ARM licensee is worse.

I'm not saying it's worse, but see the OKI ARM7 MCUs for a very 
similar device that handles booting and programming differently. 
They use a combination of external (dedicated) pins and internal 
register settings to select the boot mode (e.g. to re-flash etc.). 
Personally, I find the Philips approach simpler, easier to use and 
more flexible. It's a matter of choice though: I don't think either 
approach is seriously flawed as you state.

> I agree it is design issue.  I call it a defect in that the design
> because it did not take into account of the kind requirements one 
user
> had -- where the UART0 is operated in slave mode.
> 

Can you explain what you mean by slave mode? As a standard 
asynchronous UART, the LPC2xxx UARTs don't have any concept of 
master/slave as far as I'm aware.

> To fix this defect, one can change the software (in boot loader) or
> add hardware to work around.  The extent to which people had 
discuss
> about hardware options was what I referred to as intimidating.

Again, personally I'd agree with Robert and think the boot loader 
select pin should be dedicated to that function. However, then 
people would complain it's using up a pin that could be shared. The 
DCD clash is inconvenient if you don't spot the issue at the start 
(maybe an extra warning in the manual would help here?), but it's 
perfectly possible to design a reliable system without extra 
hardware if you understand the issue. It's certainly not necessary 
to change the boot loader software, which as I've already pointed 
out is an extremely poor strategy.

> Boot loader should be simple -- just to provide bare minimum to 
gain
> control when there is no firmware, not to provide virtual flash
> abstractions, external bus configuration or software protection.
> 

See the OKI parts for an alternative. I guess it's a matter of 
opinion on how these things are implemented. They each have their 
pros and cons. I guess if there was an optimum design that everyone 
agreed on, all parts would be the same!

Brendan

At 02:53 AM 4/29/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >
> > At 12:25 AM 4/29/2006 +0000, jayasooriah wrote:
> > >--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@>
> > >
> > > > It really stinks of an underlying HW race
> > > > condition.--- In lpc2000@yahoogroups.com, Robert Adsett
><subscriptions@...> wrote:
> > >I think the kind hardware *and* software (in the supplied Bootloader)
> > >problems on the LPC Family is without precedent.
> >
> > I've seen worse, and I've heard that the 4 bit micros used in are much
> > worse.  At least all the problems are in the peripherals and most
>have SW
> > workarounds.  Race conditions seem to have been a particular blind
>spot for
> > some reason though, most of the HW problems seem to lead back to
>some sort
> > of race.
>
>I like to know if you think any other ARM licensee is worse.

Who said anything about ARM licensees?  If you make a broad statement like 
the above you have to expect a response in kind.

> > DCD/ISP is a design issue not a SW or HW bug.
>
>I agree it is design issue.  I call it a defect in that the design
>because it did not take into account of the kind requirements one user
>had -- where the UART0 is operated in slave mode.

Every design fails to meet some user requirement, that's one reason we have 
so many variations on the micro theme.  That doesn't make that failure a 
bug in either SW or HW.  The STR7 series fails to meet my serial ISP 
requirement for instance, even though the original user manuals indicated 
it was supported.  Now that was a bug (Now there is an argument for a flash 
based boot loader).  On the other hand the Intel 196 doesn't support serial 
ISP at all, that's not a bug.

They had to assign the pin somewhere.  No doubt they had their reasons for 
the choice they made.  No matter where they put it, it would have caused 
someone a problem.  If there is a fault here it's in the documentation.

>To fix this defect, one can change the software (in boot loader) or
>add hardware to work around.  The extent to which people had discuss
>about hardware options was what I referred to as intimidating.

Apparently you are easily intimidated and have not been around very many 
usenet discussions :)  I know of forums where this would have trailed off 
into a discussion of how few transistors you could do it in.

And I still don't consider this a defect.

> > Personally I don't think the
> > ISP pin should have bee multiplexed at all but other micros do similar
> > things with similar consequences if the data sheets are not read
>carefully
> > and the startup conditions fully considered.
>
>One big difference I found in other micros whose feature the LPC seems
>to emulate.  They have these features designed more completely and
>have it implemented in hardware.
>
>In the case of LPC, the boot loader firmware attempts to mimic these
>features, and they have chosen the deferred design approach to leave
>this in firmware for future updates.
>
>Boot loader should be simple -- just to provide bare minimum to gain
>control when there is no firmware, not to provide virtual flash
>abstractions, external bus configuration or software protection.

Even if I were to agree with all of the above it doesn't negate the point 
that the primary issue is that the startup conditions must be fully 
considered when designing in a micro, whether the resulting restrictions 
are the result of internal HW or internal SW is utterly irrelevant.  I 
suspect we have all missed a startup condition at one point or 
another.  I'm certain we've all found user documentation to be misleading 
at some point.

>The mistake IMO Philips did in incorporating these functions into a
>boot loader is that they had to make it upgradeable (given things go
>wrong as we have seen) and in the process, ended up with the situation
>where it is possible to lock out the hardware by software.  I know of
>no other system that does.  OTPs are different of course by design.

Um how do you lock out the HW in software?  You always have serial ISP 
available.

On the other hand From Luminary Micros Documentation

"Caution – If the JTAG pins will be used as GPIOs, it is possible to create 
a software sequence that
prevents the debugger from connecting to the Stellaris microcontroller. If 
the program code loaded
into flash immediately changes the JTAG pins to their GPIO functionality, 
the debugger will not
have enough time to connect and halt the controller before the JTAG pin 
functionality switches.
This locks the debugger out of the part. This can be avoided with a 
software routine that restores
JTAG functionality using an external trigger."

Since this appears to be how the micro is programmed it is quite possible 
to lock out the chip in SW.  So that suggests there is at least one micro 
that is possible to lock out the HW with SW.

>Having to condition analog input in order to use watchdog is a serious
>design defect.  The fix is simple if it were done in the bootloader.
>It is the obvious solution.  Saves having endless discussion on how to
>solve this defect with yet another gate or chip.

What errata is that?  And how do you fix an failure to condition an analog 
input by changing the bootloader?

Besides which, surely conditioning an analog input is just basic 
design?  Is there something special needed?

> > Despite the fact I'd like to see Philips being a little faster about
> > acknowledging bugs they do at least make the errata easily available.
>
>Everyone does these days and through the web.  Gone are the days when
>I had to chase suppliers to get the technical contact, and then have
>to explain why I need the latest errata sheet for the engineering
>sample I working on.

I still run into that on occasion.  Web access makes proliferation easier 
but only when the company involved decides to publish the errata to begin with.

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/

> > Boot loader should be simple -- just to provide bare minimum to
> gain
> > control when there is no firmware, not to provide virtual flash
> > abstractions, external bus configuration or software protection.

The boot loader of Phillips P89V51RD2 is much simpler, it waits for activity
at serial port after reset, and if found enters bootloader mode. No pins.

Phillips could have used this logic!! just a thought!!

Best Regards,

Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> wrote:
> > I like to know if you think any other ARM licensee is worse.
> 
> I'm not saying it's worse ...

There is no precedent then.

> but see the OKI ARM7 MCUs for a very 
> similar device ...

A world of difference.

> Can you explain what you mean by slave mode?

The master is the device (modem or processor) that comes up first.

> See the OKI parts for an alternative.

I have and I see a world of difference.

One just has to look at the humungus that Philips Flash Utility tool
that one has to install and maintain on the host.  Flash block sizes
are all over the place, etc.

Have a look at my boot sector diagnostics tool -- it gives you all the
information one needs to know about the device, including the crystal
frequency without having to "install" anything.

Unlike Philips, OKI designers appear to appreciate KISS rule book. If
anyone things they are in the same league, then I suspec they are
either kidding themselves or just plain naive.

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >I like to know if you think any other ARM licensee is worse.
> 
> Who said anything about ARM licensees?  If you make a broad
statement like 
> the above you have to expect a response in kind.

Perhaps I should have said comparing 4-bit controller to 32-bit ARM is
like comparing apples to oranges :)

> They had to assign the pin somewhere.  No doubt they had their
reasons for 
> the choice they made.  No matter where they put it, it would have
caused 
> someone a problem.

Some solutions cause more problem than others.

> Um how do you lock out the HW in software?  You always have serial ISP 
> available.

ISP relies on the contents of boot sector being kept intact.

It is possible to erase or corrupt the boot sector given this section
of on-chip flash is not protected and does not have SDP or equivalent.

If the (bad) software in the boot block disables JTAG and hangs, then
hardare is useless if we are to accept what we are told.

> >Having to condition analog input in order to use watchdog is a serious
> >design defect.  The fix is simple if it were done in the bootloader.
> >It is the obvious solution.  Saves having endless discussion on how to
> >solve this defect with yet another gate or chip.
> 
> What errata is that?  And how do you fix an failure to condition an
analog 
> input by changing the bootloader?

I think it not in the errata because it is a "feature".

The boot loader sets up external bus interface based on reset
(includign watchdog reset) by reading digital state of ADC input.

This cannot be a sensible thing to do IMO.

> Besides which, surely conditioning an analog input is just basic 
> design?  Is there something special needed?

Conditioning as in making sure it analog inputs are pulled high
whenever the watchdog fires?

How is it possible to do this without ... on yes add an external
watchdog becasue the internal watchdog is useless in this case!

Jaya

--- In lpc2000@yahoogroups.com, Mukund Deshmukh <betacomp_ngp@...> wrote:

> The boot loader of Phillips P89V51RD2 is much simpler, it waits for
activity
> at serial port after reset, and if found enters bootloader mode. No
pins.
> 
> Phillips could have used this logic!! just a thought!!

I can see that the quantum of time being an issue.  Some like it large
but others cannot afford to wait that long.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
> > Can you explain what you mean by slave mode?
> 
> The master is the device (modem or processor) that comes up first.
> 

I've never seen this usage before in relation to a communications 
interface. Conventional usage of the term master/slave in the context 
of a serial port is where communications between systems is not 
symmetric.

> Unlike Philips, OKI designers appear to appreciate KISS rule book. If
> anyone things they are in the same league, then I suspec they are
> either kidding themselves or just plain naive.
> 

I've also used both parts and have come to a different conclusion. The 
difference between us is that I don't feel the need to innsult others 
with a different opinion. I've asked you before to refrain from this 
kind of language: it only detracts from the points you make.

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> > Unlike Philips, OKI designers appear to appreciate KISS rule book. If
> > anyone things they are in the same league, then I suspec they are
> > either kidding themselves or just plain naive.
> > 
> 
> I've also used both parts and have come to a different conclusion. The 
> difference between us is that I don't feel the need to innsult others 
> with a different opinion. I've asked you before to refrain from this 
> kind of language: it only detracts from the points you make.

It depends on how you take my comment Brendan.

I say there is no comparison and yet you keep butting in that they are
alike.  Either you cannot see what I see, or you do not know enough to
see the difference I see.

Just so that others can see the kind of differences we are talking
about, here is an excerpt of OKI user manual for 674001/675001 series:

<quote>

6.2 Reset Types

6.2.1 External Reset Input
Driving the RESET_N pin at Low level for a pulse width at least 20
clock cycles triggers a reset. When first applying the power or waking
the LSI from STANDBY mode, however, increase the pulse width to at
least 10 ms to allow the crystal oscillator sufficient time to stabilize.

This type of reset leaves 0x0000 in the WDSTAT register.

6.2.2 Watchdog Timer Overflow
Setting the ITM and OFINTMODE bits in the watchdog time base counter
control (WDTBCON) register to "0" and "1," respectively, causes
watchdog timer overflow to trigger a system reset.

This type of reset leaves 0x0001 in the WDSTAT register.

This type also leaves the following LSI settings unchanged: I/O port
direction (input/output), I/O port function (primary/secondary), I/O
port output levels, and the oscillation stabilization interval
specified in the clock wait (CKWT) register.

</quote>

The designers have thought through what one uses the watchdog for and
chose not to lump watchdog reset with the system reset as it appears
to be for LPC.  Clearly there is no comparison.

If you wish to question one's assessment, or make your own counter
assertion you must be prepared not to be offended when one explains
how far off the mark you assertions are.

Jaya

Robert Adsett wrote:

>At 04:47 PM 4/28/2006 -0400, Tom Walsh wrote:
>  
>
>>Robert Adsett wrote:
>>    
>>
>>>Quoting bacalaoencebollao <bacalaoencebollao@...>:
>>>      
>>>
>>>>I have a problem with my programme, i want to make my UART work, but
>>>>without the FIFOs, is there anyway to get a receive interrupt when
>>>>only one character has been recieved, or do I have to wait for the
>>>>FIFO to be full?
>>>>
>>>>
>>>>        
>>>>
>>>The FIFO must be turned on.
>>>
>>>However, you will recieve an interrupt on a single character.  It will 
>>>      
>>>
>>just be
>>    
>>
>>>delayed (by 1.5 character time IIRC).  That allows the buffer to fill for a
>>>stream of characters but interrupt on pauses in the stream if there are
>>>characters waiting in the FIFO.
>>>
>>>
>>>
>>>      
>>>
>>I run interrupt driven I/O on UART0 without the FIFO turned on...  Seems
>>to work fine for me on the LPC2138 and LPC2106.
>>    
>>
>
>It's a nasty little bug Tom, I was running w/o the FIFOs on and ran into a 
>problem that I eventually 'fixed' by only reading the IIR once per 
>interrupt.  Before that under an echo load the serial interrupts would 
>occasionally stop.  (My test was a simple echo test and it would take 
>several hours to fail at full load)  Note that these tests were on a 2106.
>
>  
>
Robert, thanks for the info on this.  I'll have to do some more testing 
on the LPC2000 uarts.  Most stringent testing has been on the SPI + 
MAX3100 uarts.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> It depends on how you take my comment Brendan.
> 
> I say there is no comparison and yet you keep butting in that they 
are
> alike.  Either you cannot see what I see, or you do not know 
enough to
> see the difference I see.

I think you should read again what I actually said, which 
was: "...but see the OKI ARM7 MCUs for a very similar device that 
handles booting and programming differently". How do you equate the 
word "differently" to "they are alike"? 

> This type of reset leaves 0x0001 in the WDSTAT register.
> 
> This type also leaves the following LSI settings unchanged: I/O 
port
> direction (input/output), I/O port function (primary/secondary), 
I/O
> port output levels, and the oscillation stabilization interval
> specified in the clock wait (CKWT) register.
> 
> </quote>
> 
> The designers have thought through what one uses the watchdog for 
and
> chose not to lump watchdog reset with the system reset as it 
appears
> to be for LPC.  Clearly there is no comparison.

To my way of thinking it is preferable to have a watchdog reset the 
system to a known state, rather than leave it in some unknown state: 
who knows what state the peripherals are in when the system's 
software (probable cause of the watchdog reset) may have done 
anything in the lead up to the watchdog being triggered? 

I'm not going to labor this point: we clearly have different views. 

> 
> If you wish to question one's assessment, or make your own counter
> assertion you must be prepared not to be offended when one explains
> how far off the mark you assertions are.

I'm not in the least offended: I've been called much worse. My point 
was advise to you that people will pay more attention to your 
arguments if you refrain from using abusive and derogatory language. 
In my experience the respect one gets for one's opinions is in 
inverse proportion to the amount of abuse one gives out. My guess is 
that a lot of people will have long since discounted anything you 
post here due to the tone and language you use.

By the way, I've nothing further too add to this topic: it's already 
lost its original usefulness (a warning to be careful of how the 
boot-loader select pin can be inadvertantly asserted, and practical 
suggestions of how to avoid the problem). I would imagine the 
interest in whether you or I think the Philips or OKI part is a 
better design is somewhat limited to say the least.

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
> I think you should read again what I actually said, which 
> was: "...but see the OKI ARM7 MCUs for a very similar device that 
> handles booting and programming differently". How do you equate the 
> word "differently" to "they are alike"?

I do not.  I equate "very similar devices" above to mean "alike".

To refresh your memory, I started this thread with the statement:

> I think the kind (of) hardware *and* software (in the supplied
> Bootloader) problems on the LPC Family is without precedent.

The differences are significant.  Unlike the LPC, both OKI and SAM
have: JEDEC compliant SDP flash; both watchdog *and* analog inputs can
be used; cannot be locked out by corrupt software; and so on.

One has to try come up with what is good about LPCs to appreciate this
sentiment.

> To my way of thinking it is preferable to have a watchdog reset the 
> system to a known state, rather than leave it in some unknown state: 
> who knows what state the peripherals are in when the system's 
> software (probable cause of the watchdog reset) may have done 
> anything in the lead up to the watchdog being triggered?

This thinking goes against the "keep options open" rule of good system
design.

The user (like you) can set everything back to the reset state if they
so wished.  In the LPC, it does it for you in a way that watchdog and
analog inputs are mutually exclusive resources.

This cannot be considered a good design.

> By the way, I've nothing further too add to this topic: it's already 
> lost its original usefulness (a warning to be careful of how the 
> boot-loader select pin can be inadvertantly asserted, and practical 
> suggestions of how to avoid the problem).

Looks like you have not noticed the change in thread title ...

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> The user (like you) can set everything back to the reset state if 
they so wished. 

Maybe if you had experience of a peripheral that can't be reset by 
software you'd have a different view. The UARTs in some members of 
the NEC V850 familiy have this "feature": they can get locked into 
modes that only a hardware reset can clear.

By definition (unless it's being used to implement something like 
a "soft reset" feature), when a watchdog has expired the system is 
in an unusual and unknown state. I'd much rather a system that the 
watchdog is guaranteed to get it back into a known, initial state 
than run the risk of being the first to discover the peripheral and 
mode that can't be recovered by software. The Philips part (and most 
others for that matter) gives this guarentee: a watchdog reset is 
the same as a power-on or hard reset (other than the reset source 
identifier). That's just the way I like it, thanks.

> In the LPC, it does it for you in a way that watchdog and
> analog inputs are mutually exclusive resources.

Can you explain the issue here, please? Why are analog i/ps and the 
watchdog mutually exclusive?

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> wrote:
> > The user (like you) can set everything back to the reset state if 
> they so wished. 
> 
> Maybe if you had experience of a peripheral that can't be reset by 
> software you'd have a different view.

I would not change my view.  I would move on to a processor chip that
does not have this type of nastiness.

> The UARTs in some members of 
> the NEC V850 familiy have this "feature": they can get locked into 
> modes that only a hardware reset can clear.

If NEC recommends that you needs to use the watchdog timer to recover
from UART lockups that cannot be recovered by software, my advice to
you is to move on to another vendor.  The market is full of alternatives.

> By definition (unless it's being used to implement something like 
> a "soft reset" feature), when a watchdog has expired the system is 
> in an unusual and unknown state.

This begs the question as to the purpose of the watchdog timer.  To
break deadlocks in hardware (CPU, UARTs, etc) or software?

If a manufacture tells you it is to break hardware deadlocks, my
advice is that you move on to one that does not.

> I'd much rather a system that the 
> watchdog is guaranteed to get it back into a known, initial state 
> than run the risk of being the first to discover the peripheral and 
> mode that can't be recovered by software.

If a peripheral locks up and cannot be recovered by re-initialisation,
it is time to move on.

Having to reset or power cycle such purposes is something most designs
will not tolerate.

> The Philips part (and most 
> others for that matter) gives this guarentee: a watchdog reset is 
> the same as a power-on or hard reset (other than the reset source 
> identifier). That's just the way I like it, thanks.

This "most others for that matter" is yet another ambit claim it
seems.  I looked at both SAM and OKI and these designs appear to have
put more thought into how one uses the watchdog.

I have already explained how OKI is different.  Here is an excerpt
from SAM user manual:

<quote>
The Watchdog Timer can be used to prevent system lock-up if the
software becomes trapped in a deadlock.
...
It can generate a general reset or a processor reset only.
</quote>

Considering Philips calls the LPC an alternative to SAM and OKI parts
whose hardware features they mimics by software, it makes sense to
compare limit comparisons with these.

Jaya

I've seen a lot of "move to another processor" here.

I'm trying hard to do that but could not.    Since you are the 
expert, could you find me an alternate ARM7 good enough??  I only
need simple features:
- Reliable Code Read Protection.
- Around 48 I/O on a LQFP64 package. The other chips are having 
  <50% of pins as I/O
- Good to have 1x Clock execution cycle at 60MHz but can go 
  without it
- Flash size 32K to 256KB, SRAM 8KB to 32KB
- Competitive pricing.
- (All USB, UART, SPI, I2C, PWM, Timers, watchdog are standard on 
  all chips.   All parts have buggy peripherals but all can be
  fixed.  What the big problem/fuss??)

In the business world (and non-academic), it is hard to move away
from philips part to another part.   I hate the Philips chips with
those CRP questions hanging around there, but sticking to using it.

Look at that depleting LPC2103 stock on digikey, do you find any
other ARM7 parts moving that fast on DigiKey??
Regards

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> >
> > --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> > wrote:
> > > The user (like you) can set everything back to the reset state 
if 
> > they so wished. 
> > 
> > Maybe if you had experience of a peripheral that can't be reset 
by 
> > software you'd have a different view.
> 
> I would not change my view.  I would move on to a processor chip 
that
> does not have this type of nastiness.
> 
> > The UARTs in some members of 
> > the NEC V850 familiy have this "feature": they can get locked 
into 
> > modes that only a hardware reset can clear.
> 
> If NEC recommends that you needs to use the watchdog timer to 
recover
> from UART lockups that cannot be recovered by software, my advice 
to
> you is to move on to another vendor.  The market is full of 
alternatives.
> 
> > By definition (unless it's being used to implement something 
like 
> > a "soft reset" feature), when a watchdog has expired the system 
is 
> > in an unusual and unknown state.
> 
> This begs the question as to the purpose of the watchdog timer.  To
> break deadlocks in hardware (CPU, UARTs, etc) or software?
> 
> If a manufacture tells you it is to break hardware deadlocks, my
> advice is that you move on to one that does not.
> 
> > I'd much rather a system that the 
> > watchdog is guaranteed to get it back into a known, initial 
state 
> > than run the risk of being the first to discover the peripheral 
and 
> > mode that can't be recovered by software.
> 
> If a peripheral locks up and cannot be recovered by re-
initialisation,
> it is time to move on.
> 
> Having to reset or power cycle such purposes is something most 
designs
> will not tolerate.
> 
> > The Philips part (and most 
> > others for that matter) gives this guarentee: a watchdog reset 
is 
> > the same as a power-on or hard reset (other than the reset 
source 
> > identifier). That's just the way I like it, thanks.
> 
> This "most others for that matter" is yet another ambit claim it
> seems.  I looked at both SAM and OKI and these designs appear to 
have
> put more thought into how one uses the watchdog.
> 
> I have already explained how OKI is different.  Here is an excerpt
> from SAM user manual:
> 
> <quote>
> The Watchdog Timer can be used to prevent system lock-up if the
> software becomes trapped in a deadlock.
> ...
> It can generate a general reset or a processor reset only.
> </quote>
> 
> Considering Philips calls the LPC an alternative to SAM and OKI 
parts

> whose hardware features they mimics by software, it makes sense to
> compare limit comparisons with these.
> 
> Jaya
>

At 05:26 AM 4/29/2006 -0400, Tom Walsh wrote:
>Robert Adsett wrote:
> >It's a nasty little bug Tom, I was running w/o the FIFOs on and ran into a
> >problem that I eventually 'fixed' by only reading the IIR once per
> >interrupt.  Before that under an echo load the serial interrupts would
> >occasionally stop.  (My test was a simple echo test and it would take
> >several hours to fail at full load)  Note that these tests were on a 2106.
> >
> >
> >
>Robert, thanks for the info on this.  I'll have to do some more testing
>on the LPC2000 uarts.  Most stringent testing has been on the SPI +
>MAX3100 uarts.

Glad to help Tom, I'd like any information I could get on this. Until I 
know what the underlying cause is I won't be comfortable that I've 
completely eliminated it.

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/

At 08:29 AM 4/29/2006 +0000, jayasooriah wrote:
>Just so that others can see the kind of differences we are talking
>about, here is an excerpt of OKI user manual for 674001/675001 series:
>
><quote>
>
>6.2 Reset Types
>
>6.2.1 External Reset Input
>Driving the RESET_N pin at Low level for a pulse width at least 20
>clock cycles triggers a reset. When first applying the power or waking
>the LSI from STANDBY mode, however, increase the pulse width to at
>least 10 ms to allow the crystal oscillator sufficient time to stabilize.
>
>This type of reset leaves 0x0000 in the WDSTAT register.
>
>6.2.2 Watchdog Timer Overflow
>Setting the ITM and OFINTMODE bits in the watchdog time base counter
>control (WDTBCON) register to "0" and "1," respectively, causes
>watchdog timer overflow to trigger a system reset.
>
>This type of reset leaves 0x0001 in the WDSTAT register.
>
>This type also leaves the following LSI settings unchanged: I/O port
>direction (input/output), I/O port function (primary/secondary), I/O
>port output levels, and the oscillation stabilization interval
>specified in the clock wait (CKWT) register.
>
></quote>
>
>The designers have thought through what one uses the watchdog for and
>chose not to lump watchdog reset with the system reset as it appears
>to be for LPC.  Clearly there is no comparison.

So the difference would be
         - Leaves a different signature behind
         - Leaves the I/O in the state it was, quite possibly increasing 
the latency to a known good state.

The LPC does the first as well,  The second it does differently.  Better as 
far as I'm concerned.  However both are reasonably easily dealt with.  Only 
when running close to the edge would that be a deciding factor in choosing 
one over the other.

Not all processors distinguish between reset sources.

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/

At 05:38 AM 4/29/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > >I like to know if you think any other ARM licensee is worse.
> >
> > Who said anything about ARM licensees?  If you make a broad
>statement like
> > the above you have to expect a response in kind.
>
>Perhaps I should have said comparing 4-bit controller to 32-bit ARM is
>like comparing apples to oranges :)

Hey, you said unprecedented w/o adding any restriction :)  Yeah 4 bit 
stretches it but that was rather the point I was trying to make.  However 
it does compare nicely with 16 bit and a number of the higher end 8 bit micros.

> > They had to assign the pin somewhere.  No doubt they had their
>reasons for
> > the choice they made.  No matter where they put it, it would have
>caused
> > someone a problem.
>
>Some solutions cause more problem than others.

Well that depends on the perspective, I can certainly think of worse 
choices and effectively eliminating DCD is a pretty minor effect with 
fairly straightforward workarounds if you need DCD.  As far as I'm 
concerned P0.14 has no other purpose than invoking ISP.


> > Um how do you lock out the HW in software?  You always have serial ISP
> > available.
>
>ISP relies on the contents of boot sector being kept intact.
>
>It is possible to erase or corrupt the boot sector given this section
>of on-chip flash is not protected and does not have SDP or equivalent.

SDP??

Ah yes, the corrupted boot block.  You know in the 2 1/2 years I've been 
following this list I've seen I think three reports of boot block 
corruption.  An early report which was basically a friend of a stranger 
report, your report which was the most detailed and one other that was 
later withdrawn .

> > >Having to condition analog input in order to use watchdog is a serious
> > >design defect.  The fix is simple if it were done in the bootloader.
> > >It is the obvious solution.  Saves having endless discussion on how to
> > >solve this defect with yet another gate or chip.
> >
> > What errata is that?  And how do you fix an failure to condition an
>analog
> > input by changing the bootloader?
>
>I think it not in the errata because it is a "feature".
>
>The boot loader sets up external bus interface based on reset
>(includign watchdog reset) by reading digital state of ADC input.
>
>This cannot be a sensible thing to do IMO.

Reference please.  I don't use chips large enough to demand external memory 
(really 256K is luxurious).  I did take a quick look at the 2200's though 
and found boot0 &1 which appear to control the startup bus but they are 
multiplexed with the data lines not A/D inputs.  I only took a quick look 
at a few variants though.

Given that it's true though I fall back to what I said earlier about having 
to take into account startup conditions when you design a system.  That's 
why you have to read both the data sheet and user manual before selecting a 
chip.  Also errata and user experiences.

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/

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> I've seen a lot of "move to another processor" here.

I did not realise I said this so many times in one post!  Must be I
was trying to tell the poster something ... :)

> I'm trying hard to do that but could not.

Having already made the selection, you have to weigh costs of moving
against maintaining status quo.

I have see two cases where having made the selection, they had to move:

1/  Student Lab Kit:  LPC does not allow flash to be locked down. 
Students could (deliberately) destroy the hardware by corrupting boot
sector.  They switched to OKI.

2/  Flash Data Storage:  LPC does not allow flash to be written at
units of byte or words.  The 16-bit write requirement, ad hoc block
sizes for 256K parts coupled with its life cycle made it unsuitable
for data storage.  I am not sure if they switched to OKI or SAM.

In both cases, it did not look like the switch was more expensive.

A third case is pending on what Robert and Tom have to say about UART
issues in LPC family.

[Note that Philips has not indicated the UART bugs can be fixed, or
that it will be fixed, unlike power on reset bug.]

A fourth case is pending on what happens in July in relation depletion
of LPC stocks in the field.

> Since you are the 
> expert, could you find me an alternate ARM7 good enough??  I only
> need simple features:
> - Reliable Code Read Protection.
> - Around 48 I/O on a LQFP64 package. The other chips are having 
>   <50% of pins as I/O
> - Good to have 1x Clock execution cycle at 60MHz but can go 
>   without it
> - Flash size 32K to 256KB, SRAM 8KB to 32KB
> - Competitive pricing.
> - (All USB, UART, SPI, I2C, PWM, Timers, watchdog are standard on 
>   all chips.   All parts have buggy peripherals but all can be
>   fixed.  What the big problem/fuss??)

Flattery will not get me doing the selection chart for you :)

The designs I have seen where client does not want the product cloned
by copying hardware and the software, especially when software is the
value item, do not use LPCs.  AVRs seem to be the popular choice.

As for flash speed, I understand LPC is not as fast as SAM and maybe
even OKI.  Have a look at guaranteed speeds and write/erase times.  I
dont know why you consider LPC flash as fastest.

The other reason to stay away from LPC flash is that it is in its
infant stage -- there are a number of implementation bugs to be ironed
out before it becomes as usable like other flash architectures.  At
the moment it is good for OTP needs but with the advantage that field
upgrades are possible.

Hope this helps.

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> So the difference would be
>          - Leaves a different signature behind
>          - Leaves the I/O in the state it was, quite possibly
increasing 
> the latency to a known good state.
> 
> The LPC does the first as well,  The second it does differently. 
Better as 
> far as I'm concerned.  However both are reasonably easily dealt
with.  Only 
> when running close to the edge would that be a deciding factor in
choosing 
> one over the other.

The approach you refer to as "better" is IMO flawed for the following
reason:

In the hardware approach, external bus sizing only takes place on
power on reset.  External bus is invariant for any given system and
thus a watchdog (or even external reset) does not change this.

In the LPC approach, the watchdog reset does not preserve bus size
setting because it does a system reset as a blind reset.

So when a watchdog fires, external bus sizing has to be done all over
again by software ... but the pins now have taken on a different role
because these are used as GPIO!

There is no way out.  Watchdog reset and "GPIO" usage of BOOT0 and
BOOT1 pins are mutually exclusive.  The external device driving this
input has no way of knowing when the watchdog fires.

In fact, if you think about this carefully, if you are using watchdog
timer, then you cannot use these pins for output either because these
have to be strapped so that it does the right thing every time the
watchdog fires.

In an earlier post I mistakenly said these were analog inputs.  You
are right that these are digital inputs.

Analog or digital input or output, the fact remains that these pins
cannot be used if one uses the watchdog.  I bet Philips throught it
would be a good idea to sell these bus size strapping pins as GPIO!

Jaya

Hi, Mr Jaya,
Apologize for my poor english, such that you completely missed
my points. Let me re-phrase it to simple questions:

I want to switch away from LPC2103 and LPC2132/6.  Could you the
expert (who disqualify/condemn the Philips parts) help to find some
replacement chips for me??  Only simple chip features needed!!
- Reliable Code Read Protection.
- Around 48 I/O on the LQFP64 package. and 32 I/O on LQFP48
- Good to have 1x Clock execution cycle at 60MHz but can go 
  without it
- Flash size 32K to 256KB, SRAM 8KB to 32KB
- Competitive pricing.  Available from Digikey a plus.
- (All USB, UART, SPI, I2C, PWM, Timers, watchdog are standard 
  features on all vendors' chips.   All vendor's parts have buggy
  peripherals but all can be fixed by software.  So what's the 
  big problem/fuss??)

Name me another vendor's ARM7 chip first.   Before you try to
confuse me more with those "cost of moving" and etc...  or 
Student's lab-kit??  Which are supposed to be on 8-bit?? 

I'm not interested in debating on chip's features.   Just name me a
good ARM7 alternative replacement for LPC2103, LPC2134/36 and you
get rid of one of your opponents immediately (I will switch
to "that" new chip's discussion group)....  :)
Regards



--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@> wrote:
> >
> > I've seen a lot of "move to another processor" here.
> 
> I did not realise I said this so many times in one post!  Must be I
> was trying to tell the poster something ... :)
> 
> > I'm trying hard to do that but could not.
> 
> Having already made the selection, you have to weigh costs of 
moving
> against maintaining status quo.
> 
> I have see two cases where having made the selection, they had to 
move:
> 
> 1/  Student Lab Kit:  LPC does not allow flash to be locked down. 
> Students could (deliberately) destroy the hardware by corrupting 
boot
> sector.  They switched to OKI.
> 
> 2/  Flash Data Storage:  LPC does not allow flash to be written at
> units of byte or words.  The 16-bit write requirement, ad hoc block
> sizes for 256K parts coupled with its life cycle made it unsuitable
> for data storage.  I am not sure if they switched to OKI or SAM.
> 
> In both cases, it did not look like the switch was more expensive.
> 
> A third case is pending on what Robert and Tom have to say about 
UART
> issues in LPC family.
> 
> [Note that Philips has not indicated the UART bugs can be fixed, or
> that it will be fixed, unlike power on reset bug.]
> 
> A fourth case is pending on what happens in July in relation 
depletion
> of LPC stocks in the field.
> 
> > Since you are the 
> > expert, could you find me an alternate ARM7 good enough??  I only
> > need simple features:
> > - Reliable Code Read Protection.
> > - Around 48 I/O on a LQFP64 package. The other chips are having 
> >   <50% of pins as I/O
> > - Good to have 1x Clock execution cycle at 60MHz but can go 
> >   without it
> > - Flash size 32K to 256KB, SRAM 8KB to 32KB
> > - Competitive pricing.
> > - (All USB, UART, SPI, I2C, PWM, Timers, watchdog are standard 
on 
> >   all chips.   All parts have buggy peripherals but all can be
> >   fixed.  What the big problem/fuss??)
> 
> Flattery will not get me doing the selection chart for you :)
> 
> The designs I have seen where client does not want the product 
cloned
> by copying hardware and the software, especially when software is 
the
> value item, do not use LPCs.  AVRs seem to be the popular choice.
> 
> As for flash speed, I understand LPC is not as fast as SAM and 
maybe
> even OKI.  Have a look at guaranteed speeds and write/erase 
times.  I
> dont know why you consider LPC flash as fastest.
> 
> The other reason to stay away from LPC flash is that it is in its
> infant stage -- there are a number of implementation bugs to be 
ironed
> out before it becomes as usable like other flash architectures.  At
> the moment it is good for OTP needs but with the advantage that 
field

> upgrades are possible.
> 
> Hope this helps.
> 
> Jaya
>

>Given that it's true though I fall back to what I said earlier about having 
>to take into account startup conditions when you design a system.  That's 
>why you have to read both the data sheet and user manual before selecting a 
>chip.  Also errata and user experiences.
>
>  
>
Yeah, and one or two working prototypes certainly help.  heh.

I've been burned in the past by deploying a design, only to find out 
about 6 years later that an expansion path to a larger EPROM was 
closed.  I'd made a mistake on the banking logic, actually gave drafting 
the wrong schematic and never caught it until I needed it.

I just assUmed that since the proto worked that the production board was 
ok.  Doh!

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > > Um how do you lock out the HW in software? ...
> >ISP relies on the contents of boot sector being kept intact.
> > ...
> >It is possible to erase or corrupt the boot sector given
> >this section of on-chip flash is not protected and does
> > not have SDPor equivalent.
> 
> SDP??

Google comes to the rescue ... have a look at:

  http://www.sst.com/downloads/app_note/S72027.pdf

> Ah yes, the corrupted boot block.  You know in the 2 1/2
> years I've been following this list I've seen I think three
> reports of boot block corruption.
> An early report which was basically a friend of a stranger 
> report, your report which was the most detailed and one
> other that was later withdrawn.

I am not sure what kind of inferences one can draw from this.

I certainly have a quite a few who know me through this forum telling
me privately how much they regret going down the LPC path.

I do not think we will hear them say this in this forum until the
abuse one gets when one expresses a view that is not flattering to
Philips or LPC stops.

SDP or not, surely you have to agree that LPC chip hardware can be
locked out software.

My most favourite example of how not to design systems used to be a
certain storage oscilloscope in which the yoke drivers go up in smoke
each time you address the cursor to a point outside the screen.

I guess LPC is a modern day equivalent.

Jaya

Earlier I said ...

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

> > The LPC does the first as well,  The second it does differently. 
> Better as 
> > far as I'm concerned.  However both are reasonably easily dealt
> with.  Only 
> > when running close to the edge would that be a deciding factor in
> choosing 
> > one over the other.
> 
> The approach you refer to as "better" is IMO flawed ...

Apologies if I misunderstood as to which method you said as better.

In addition reasons I gave, I forgot to mention one obvious drawback.

If you have a requirement that you must recover from watchdog reset
without the outside world knowing about this, then the LPC approach
fails where the second method works.

Jaya,

> My most favourite example of how not to design systems used to be a
> certain storage oscilloscope in which the yoke drivers go up in smoke
> each time you address the cursor to a point outside the screen.
> 
> I guess LPC is a modern day equivalent.

With all the negative, posts you making about the LPC
series of parts, what is the point of your continued
investigation of the part.

Some of your points can be taken as "another way to do
things" but you continue to dismiss the fact that others may do
things differently.

By not accepting that there may be more than one way to
do things it makes you appear to be inflexible and unwilling
to see another point of view.

Indeed, it makes you look rather arrogant, and this can be
discovered easily by a quick Google from a prospective client.

Ralph

Jaya,

> The approach you refer to as "better" is IMO flawed for the following
> reason:
> 
> In the hardware approach, external bus sizing only takes place on
> power on reset.  External bus is invariant for any given system and
> thus a watchdog (or even external reset) does not change this.

This is not always true an all chip families. In fact, I had
an HC16 system that used an external 8 bit wide FLASH for code and
config data storage.

At boot time, the 8 bit FLASH provided basic bootstrap code, which
included copying code and data to faster 16 bit RAM. The HC16 had smart
chip select logic than knew whether a peripheral was 8 or 16 bits
wide.

> In the LPC approach, the watchdog reset does not preserve bus size
> setting because it does a system reset as a blind reset.
> 
> So when a watchdog fires, external bus sizing has to be done all over
> again by software ... but the pins now have taken on a different role
> because these are used as GPIO!

That's the entire point. The watchdog fires and resets the system
to a known state. The previous use of the pin is not relevant.

> There is no way out.  Watchdog reset and "GPIO" usage of BOOT0 and
> BOOT1 pins are mutually exclusive.  The external device driving this
> input has no way of knowing when the watchdog fires.

I have not double checked this on the LPC parts, but on the HC16
system I designed, only weak pullups were used on the pins that
defined bus sizing and other at-reset conditions.

Once the chip was up and running, the pins were used for things
like address and data lines, and the pullups did not affect
their operation.

Like I have suggested in a previous post, your continued lack
of flexibility makes you appear arrogant, which is not one of the
things I would be looking for in a consultant.

Ralph

--- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@...> wrote:
> > My most favourite example of how not to design systems used to be a
> > certain storage oscilloscope in which the yoke drivers go up in smoke
> > each time you address the cursor to a point outside the screen.
> > 
> > I guess LPC is a modern day equivalent.
> 
> With all the negative, posts you making about the LPC
> series of parts, what is the point of your continued
> investigation of the part.

I do not know what you mean by "investigating".  I am not studying the
LPC for any purpose or anyone.  I am simply working on it for clients
and post problems as I come across them.

You seem to suggest I should not post problems in this forum, or that
I am not entitled to make a one line remark that you seem to take
issue with.

> Some of your points can be taken as "another way to do
> things" but you continue to dismiss the fact that others may do
> things differently.
> 
> By not accepting that there may be more than one way to
> do things it makes you appear to be inflexible and unwilling
> to see another point of view.

I suppose any critique can be misconstrued this way.

> Indeed, it makes you look rather arrogant, and this can be
> discovered easily by a quick Google from a prospective client.

I have no idea what you are referring to here.

Jaya

At 07:19 AM 4/30/06 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > So the difference would be
> >          - Leaves a different signature behind
> >          - Leaves the I/O in the state it was, quite possibly
>increasing
> > the latency to a known good state.
> >
> > The LPC does the first as well,  The second it does differently.
>Better as
> > far as I'm concerned.  However both are reasonably easily dealt
>with.  Only
> > when running close to the edge would that be a deciding factor in
>choosing
> > one over the other.
>
>The approach you refer to as "better" is IMO flawed for the following
>reason:
>
>In the hardware approach, external bus sizing only takes place on
>power on reset.  External bus is invariant for any given system and
>thus a watchdog (or even external reset) does not change this.

Um, Jaya I wasn't referring to external bussed units here.  The issue of 
bus sizing is a separate issue from the rest of the watchdog issues.

>In the LPC approach, the watchdog reset does not preserve bus size
>setting because it does a system reset as a blind reset.
>
>So when a watchdog fires, external bus sizing has to be done all over
>again by software ... but the pins now have taken on a different role
>because these are used as GPIO!
>
>There is no way out.  Watchdog reset and "GPIO" usage of BOOT0 and
>BOOT1 pins are mutually exclusive.  The external device driving this
>input has no way of knowing when the watchdog fires.
>
>In fact, if you think about this carefully, if you are using watchdog
>timer, then you cannot use these pins for output either because these
>have to be strapped so that it does the right thing every time the
>watchdog fires.

Here, I agree with you.  Those are essentially dedicated inputs.  To me it 
looks like marketing overcame engineering sense.  Being able to claim an 
extra two inputs on a check sheet.  Mind you any unit that can afford an 
external bus should be able to afford  a '245 or similar to provide extra 
digital I/O if needed.  If I recall correctly ST did dedicate their 
equivalent lines in that fashion but like I said I don't follow the larger 
units that closely.


>In an earlier post I mistakenly said these were analog inputs.  You
>are right that these are digital inputs.
>
>Analog or digital input or output, the fact remains that these pins
>cannot be used if one uses the watchdog.  I bet Philips throught it
>would be a good idea to sell these bus size strapping pins as GPIO!

Yep,  At the very least it deserves some bold print in the user manual and 
maybe even a footnote in the datasheet as well.

BTW this would be worth adding to the tips,trick, traps section of the 
armuc wiki.

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/

--- In lpc2000@yahoogroups.com, Ralph Hempel <rhempel@...> wrote:
> > In the hardware approach, external bus sizing only takes place on
> > power on reset.  External bus is invariant for any given system and
> > thus a watchdog (or even external reset) does not change this.
> 
> This is not always true an all chip families. In fact, I had
> an HC16 system that used an external 8 bit wide FLASH for code and
> config data storage.

I do not see the point in you bringing up HC16 example.  Is this to
say that bus sizing on all types of reset is a good thing?

> At boot time, the 8 bit FLASH provided basic bootstrap code, which
> included copying code and data to faster 16 bit RAM. The HC16 had smart
> chip select logic than knew whether a peripheral was 8 or 16 bits
> wide.

The point I was making (that you seem to have missed) is that when
pins are allocated for bus sizing, *and* bus sizing takes place on all
kinds of reset (including that fired by the watchdog) then you cannot
use these pins for any other purpose.

I arrived at this conclusion after fist hearing of some problems
reported in this forum and then when I had to solve this for a client.
 If I missed out something, I am very happy for someone to explain to
me what this is.

So far no one has explained how, and I gather some are not happy with
my expressing this conclusion because it is not reported in LPC
errata.  If you check the archives, I am sure you will find that
Philips Applicaion support did say (in a different way) that you
cannot use these pins if you are using watchdog timer, and that you
have to use external watchdog timer if you need to use these pins.

> > In the LPC approach, the watchdog reset does not preserve bus size
> > setting because it does a system reset as a blind reset.
> > 
> > So when a watchdog fires, external bus sizing has to be done all over
> > again by software ... but the pins now have taken on a different role
> > because these are used as GPIO!
> 
> That's the entire point. The watchdog fires and resets the system
> to a known state. The previous use of the pin is not relevant.

Here is where I asked the question as to what the purpose of watchdog
reset is.  On other processors that do bus sizing on power on reset
only, and because this information then cannot be by software, there
is no point in resetting this information on watchdog reset.

The situation with LPC is very different.  Since the boot loader
software does the bus sizing, and this information is lost when
watchdog fires a reset, it has no choice but to do this on every kind
of reset.

> > There is no way out.  Watchdog reset and "GPIO" usage of BOOT0 and
> > BOOT1 pins are mutually exclusive.  The external device driving this
> > input has no way of knowing when the watchdog fires.
> 
> I have not double checked this on the LPC parts, but on the HC16
> system I designed, only weak pullups were used on the pins that
> defined bus sizing and other at-reset conditions.

So what happens on a watchdog reset?  Does the external world that is
driving this pin know this event did occur?  If it does, how so on the
LPC?  If not, then the external device will surely over-ride weak
pull-ups.  See my point?

> Once the chip was up and running, the pins were used for things
> like address and data lines, and the pullups did not affect
> their operation.

I agree that as an address, which is *always* an output by the CPU,
which is not to be heeded unless the CPU asserts the necessary
strobes, and which the CPU does not do when taking a reset, then this
has no ill side effects.

In the case of LPC, if you used these pins as outputs, and you are
driving it low, the external device has to be prepared to see this pin
float when the watchdog reset occurs and I would not describe this as
a GPIO.

> Like I have suggested in a previous post, your continued lack
> of flexibility makes you appear arrogant, which is not one of the
> things I would be looking for in a consultant.

Different people look for different things.  [Incidentally, I am not
looking for work through this forum.]

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >In fact, if you think about this carefully, if you are using watchdog
> >timer, then you cannot use these pins for output either because these
> >have to be strapped so that it does the right thing every time the
> >watchdog fires.
> 
> Here, I agree with you.  Those are essentially dedicated inputs.  To
me it 
> looks like marketing overcame engineering sense.  Being able to
claim an 
> extra two inputs on a check sheet.  Mind you any unit that can
afford an 
> external bus should be able to afford  a '245 or similar to provide
extra 
> digital I/O if needed.

I have seen digital outputs in parts like digital potentiometers (from
Analog Devices) on SPI bus for such purposes!

> If I recall correctly ST did dedicate their 
> equivalent lines in that fashion but like I said I don't follow the
larger 
> units that closely.

I provided my OS and applications for ST10 a while back.  Although it
was an 8-bit CPU of 8086 variety, I did find it had some nice features
that were cleverly implemented and allowed me to boot load it through
serial port.

I did not like having to write the primary loader that had to be
exactly 16 bytes long, but after I did this, I was quite happy the
designers thought through how one does this in fair detail.

Jaya

PS:  My LPC world is LPC2104/5/6 and LPC2292.  Perhaps I should make
this clear in my posts next time I make an observation.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
> I would not change my view.  I would move on to a processor chip 
that
> does not have this type of nastiness.

[..AND..]

> If NEC recommends that you needs to use the watchdog timer to 
recover
> from UART lockups that cannot be recovered by software, my advice 
to
> you is to move on to another vendor.  The market is full of 
alternatives.

[..AND..}

> If a manufacture tells you it is to break hardware deadlocks, my
> advice is that you move on to one that does not.

[..AND..]

> If a peripheral locks up and cannot be recovered by re-
initialisation,
> it is time to move on.

No need to say the same thing four times: they all miss the point in 
any case.

The point isn't that a peripheral is known to lock up (in fact, I'm 
not aware any of the LPC2xxx peripherals that exhibit this 
bevahiour), the point is that there is a risk that such a problem 
may be present and as yet undiscovered. These deveices are just too 
complex, and the systems in which they operate so numerous as to 
make a guarentee of the possibility virtually impossible.

Knowing this risk exists, I've learnt from both my own and others 
experience that the best thing to do when a watchdog expires is to 
reset everything back to a known state, and then re-configure as 
required. If this is what the watchdog does, then great.

If there's some counter argument (as to why it might be prefereble 
not to reset back to a known state), I'd love to hear it.

I believe it is always a good strategy to learn from others often 
hard-one experience.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> As for flash speed, I understand LPC is not as fast as SAM and 
maybe
> even OKI.  

I think anyone making a claim like this should provide some evidence 
to back it up.

We've done extensive, comparative benchmarks of the LPC2xxx against 
OKI and other 32-bit MCUs. 

Given that benchmarks can be used to prove anything, I'd suggest 
anyone seriously concerned about performance do their own benchmarks 
of what they're actually doing.

Similarly, anyone making a claim such as the one above should 
provide benchmarks to back it up: otherwise there's no credibility 
to the claim.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

> I certainly have a quite a few who know me through this forum telling
> me privately how much they regret going down the LPC path.
> 
> I do not think we will hear them say this in this forum until the
> abuse one gets when one expresses a view that is not flattering to
> Philips or LPC stops.
> 

You are joking when you say this, aren't you? 

On a couple of occasions now I've put forward warnings on aspects of 
unexpected behaviour with the parts, not exactly flattering to 
Philips. The only abuse I've got is from yourself.

In fact, I'd be interested to see if you could find an example of such 
abuse where you weren't involved, either in dishing it out or having 
provoked it from some individual who happened to have a different 
opinion than yourself.

Brendan

Jaya, 

> I provided my OS and applications for ST10 a while back.  Although it
> was an 8-bit CPU of 8086 variety, I did find it had some nice features
> that were cleverly implemented and allowed me to boot load it through
> serial port.

Bloody hell.  When did the C166 become an 8-bit CPU?  All registers on
the C166 are 16 bits and so is the data bus.  When did the C166 grow an
x86 instruction set?

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

Jaya said:
> PS:  My LPC world is LPC2104/5/6 and LPC2292.  Perhaps I should make
> this clear in my posts next time I make an observation.
>


I was under the impression that the LPC2104/5/6 series were older
and possibly buggier than newer parts.  I have designed in the 
LPC2102/3 and the LPC2144 parts and am about ready to roll on the 
software.
I tend to use these parts to the max BTW as far as PWM, UART, A/D 
peripheral and interrupt usage go, although in this project I only
need 2 PWM outputs (luckily, because the 2nd UART uses up the other
PWM pins).

So far I've had good communications luck with the 2012 on my first 
board.  (Haven't gotten into high gear programming yet)

Am I in for big surprises? I am prepared for a few issues such as
spurious interrupts and possible A/D problems if inputs go above
Vref, etc...   I do have a high regard for Philips products in general
and have had good luck with Philips in the past.

PS, last parts I used were Atmel AVR ATMega 32s, the architecture
of which was great and are were finally good parts as soon as
Atmel fixed their bad, bad, silicon problem which almost put my last 
company out of business. (Yes, I'm bald now) Because of Atmels lack 
of support, secrecy and denial of that problem, I will not use Atmel 
any more.


Also, is there any kind of list of commercial products that use the 
Philips LPC series ??  (or possibly a thread on this forum?)

My recent product designs are generaly power supply, LCD, 
communications oriented.

boB  K7IQ
Everett WA





--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@> 
wrote:
> > >In fact, if you think about this carefully, if you are using 
watchdog
> > >timer, then you cannot use these pins for output either because 
these
> > >have to be strapped so that it does the right thing every time 
the
> > >watchdog fires.
> > 
> > Here, I agree with you.  Those are essentially dedicated inputs.  
To
> me it 
> > looks like marketing overcame engineering sense.  Being able to
> claim an 
> > extra two inputs on a check sheet.  Mind you any unit that can
> afford an 
> > external bus should be able to afford  a '245 or similar to 
provide
> extra 
> > digital I/O if needed.
> 
> I have seen digital outputs in parts like digital potentiometers 
(from
> Analog Devices) on SPI bus for such purposes!
> 
> > If I recall correctly ST did dedicate their 
> > equivalent lines in that fashion but like I said I don't follow 
the
> larger 
> > units that closely.
> 
> I provided my OS and applications for ST10 a while back.  Although 
it
> was an 8-bit CPU of 8086 variety, I did find it had some nice 
features
> that were cleverly implemented and allowed me to boot load it 
through
> serial port.


Do you mean 8088 variety maybe ??

> 
> I did not like having to write the primary loader that had to be
> exactly 16 bytes long, but after I did this, I was quite happy the
> designers thought through how one does this in fair detail.
> 
> Jaya
> 
> PS:  My LPC world is LPC2104/5/6 and LPC2292.  Perhaps I should make
> this clear in my posts next time I make an observation.
>

At 09:11 PM 4/30/06 +0100, Paul Curtis wrote:
> > I provided my OS and applications for ST10 a while back.  Although it
> > was an 8-bit CPU of 8086 variety, I did find it had some nice features
> > that were cleverly implemented and allowed me to boot load it through
> > serial port.
>
>Bloody hell.  When did the C166 become an 8-bit CPU?  All registers on
>the C166 are 16 bits and so is the data bus.  When did the C166 grow an
>x86 instruction set?

I was wondering about that myself.  Although both use segmented memory 
addressing and are 16bit CPUs (only the 8088 and 80188 had an 8 bit 
external bus as I recall and the ST10 can be configured as an 8 bit 
external bus as well) they don't resemble one another at all.

I rather liked the ST10's interrupt structure and peripheral 
set.  Unfortunately the variant I was using was one of the buggiest micros 
I've ever used.  As it turned out the biggest problem I had was a bug in a 
commercial kernel but that was kept hidden by the cpu bugs.  I don't belive 
that was a family problem though.

I expect this is one of the CPU families the ARM is likely to shunt to the 
sidelines.  Its only advantages over the ARM are its interrupt structure 
and its peripheral set.  The latter is disappearing as more ARM variants 
become available and the ARMs are cheaper to boot.

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/

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
> Am I in for big surprises? I am prepared for a few issues such as
> spurious interrupts and possible A/D problems if inputs go above
> Vref, etc...   I do have a high regard for Philips products in 
general
> and have had good luck with Philips in the past.
> 

Bob,

In my experience, the short answer to your question is "no", provided 
you read the data sheet, user manual and errata well and keep 
everything "in-spec".

Like any micros, they have their quirks (and downright bugs), more so 
in some of the earlier parts. They're about average in this respect 
for devices of similar complexity and level of maturity.

In terms of support, Philips are pretty good at acknowledging issues 
and documenting them. Their only real weakness I've seen is the length 
of time it gets to update the documentation and the somewhat eccentric 
layout of their Web site.

Again, to emphasise, this is from my own experience: I don't claim any 
special knowledge or insight.

No doubt you'll see alternative views posted here from some who think 
the parts are so bug ridden as to be unusable. All I'd say to this is 
to look at the evidence (or lack of it) being put forward to support 
these claims and make your own mind up.

Brendan.

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> No need to say the same thing four times: they all miss the point in 
> any case.
> 
> The point isn't that a peripheral is known to lock up (in fact, I'm 
> not aware any of the LPC2xxx peripherals that exhibit this 
> bevahiour), the point is that there is a risk that such a problem 
> may be present and as yet undiscovered. These deveices are just too 
> complex, and the systems in which they operate so numerous as to 
> make a guarentee of the possibility virtually impossible.

I think you seem to miss my point: that if you find a vendor produces
devices that lockup or do not function properly (like the UART in
LPC), the costs of trying to find the bugs and working around (if this
is possible) are more than moving on to a processor with peripherals
that have a good track record.

> Knowing this risk exists, I've learnt from both my own and others 
> experience that the best thing to do when a watchdog expires is to 
> reset everything back to a known state, and then re-configure as 
> required. If this is what the watchdog does, then great.

I advice people to think of costs as an ongoing issue.  Often one
finds that a product appears to be an inexpensive initial investment,
but over the life of the project, this turns out to be more expensive.

> If there's some counter argument (as to why it might be prefereble 
> not to reset back to a known state), I'd love to hear it.

I will restate for you what I have already posted in response to
Robert's questions.

If you want the components of your system external to the CPU to
function without disruption when you take a watchdog timer interrupt,
then you need the processor to preserve its external world interface
as it was, and let you problem and incrementally recover from the
software deadlock in a way that the outside world does not even know
you took this interrupt.

This is relevant if for example you are restarting a device that is
involved talking to a remote system via modem or network.

There are lots of other reasons, and this is why other manufactures do
this.  As I said before, the purpose of the watchdog timer is for the
user to recover from a software deadlock, not a means for the
manufacturer of the device to get you out of a hardware deadlocks. 

> I believe it is always a good strategy to learn from others often 
> hard-one experience.

Critiquing the solution (be it yours or that of another person) is the
key to learning, whether it is by way of examples or experience.

Jaya

Brendan,

SAM7:

> Single Cycle Access at Up to 30 MHz in Worst Case Conditions

LPC2:

I believe Philips has said its flash runs at 20MHz (or 25MHz I cannot
remember).

This why I said LPC flash is no faster than SAM.

As for OKI, I have seen this in comparison charts, but I do not know
the basis on which they have made such a claim.

I am not "making claims" Brendan, just sharing information I have seen
in a conversation mode.

Jaya

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
> wrote:
> > As for flash speed, I understand LPC is not as fast as SAM and 
> maybe
> > even OKI.  
> 
> I think anyone making a claim like this should provide some evidence 
> to back it up.
> 
> We've done extensive, comparative benchmarks of the LPC2xxx against 
> OKI and other 32-bit MCUs. 
> 
> Given that benchmarks can be used to prove anything, I'd suggest 
> anyone seriously concerned about performance do their own benchmarks 
> of what they're actually doing.
> 
> Similarly, anyone making a claim such as the one above should 
> provide benchmarks to back it up: otherwise there's no credibility 
> to the claim.
> 
> Brendan
>

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@...> wrote:

> Bloody hell.  When did the C166 become an 8-bit CPU?  All registers on
> the C166 are 16 bits and so is the data bus.  When did the C166 grow
> an x86 instruction set?

Sorry for the Freudian slip, you are right it is 16-bit.

I did not say it had i86 instruction set.  The similarity is in the
way it addresses memory.

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:

> I expect this is one of the CPU families the ARM is likely to shunt
to the 
> sidelines.  Its only advantages over the ARM are its interrupt
structure 
> and its peripheral set.  The latter is disappearing as more ARM
variants 
> become available and the ARMs are cheaper to boot.

Portablity at the instruction set level is the reason cited in many of
the comparision charts I have seen for selecting an ARM vs other more
suitable targets.

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:

> Am I in for big surprises? I am prepared for a few issues such as
> spurious interrupts and possible A/D problems if inputs go above
> Vref, etc...   I do have a high regard for Philips products in
> general and have had good luck with Philips in the past.

I think the jury is still out.  I may become clearer in a couple of
months when the next silicon iteration hits the market.

Jaya

At 12:11 AM 5/1/2006 +0000, jayasooriah wrote:
>If you want the components of your system external to the CPU to
>function without disruption when you take a watchdog timer interrupt,
>then you need the processor to preserve its external world interface
>as it was, and let you problem and incrementally recover from the
>software deadlock in a way that the outside world does not even know
>you took this interrupt.

I prefer that the device get back to a known good state as soon as 
possible.  Keeping the output in the (possibly bad) state it was in is 
definitely the last thing I want in that eventuality.  That can be done in 
SW but it does increase the latency.

For what its worth in many other processors, like the ST10, the watchdogs 
behave in the same fashion as the LPC2000 series.

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/

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

>somewhat eccentric layout of their Web site.

That's a mighty kind way to describe it!

In order to "fix" their website, Philips simply must get engineers
more involved with it's design. It's true that many engineers (like
myself) have absolutely no artistic skills, but when you design a
website that must be used by engineers, the practical layout of
information is far more important than the artistic aspects.

If the Philips engineers were forced to get all their information from
their own website, I think it would get fixed quickly!

Eric

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:

> I prefer that the device get back to a known good state as soon as 
> possible.  Keeping the output in the (possibly bad) state it was in is 
> definitely the last thing I want in that eventuality.  That can be
done in 
> SW but it does increase the latency.

If your software is in deadlock, and output is in bad state, and you
want to set it back, it would take you no more than a few microseconds.

What is your watchdog timeout?  Milliseconds?  Seconds?  What is a few
microsecond latency in comparision?

Would you still say latency is an issue?

As for other processers doing this, sure it is okay to do this if
there are no ill side effects.  In the case of LPC we know there are
ill side effects.

I had to use watchdog on COP8 processor once in telephone hardare to
meet failsafe requrements.  It was not acceptable if the current call
in progress was interrupted by a failsafe recovery triggered by the
watchdog timer.

Any procesor that does a full reset will not meet such requirements.

Jaya

> If a peripheral locks up and cannot be recovered by
re-initialisation,
 > it is time to move on.

 > Having to reset or power cycle such purposes is something most
designs
 > will not tolerate.

 > > The Philips part (and most 
 > > others for that matter) gives this guarentee: a watchdog reset is 
 > > the same as a power-on or hard reset (other than the reset source 
 > > identifier). That's just the way I like it, thanks.

 > This "most others for that matter" is yet another ambit claim it
 > seems.  I looked at both SAM and OKI and these designs appear to have
 > put more thought into how one uses the watchdog.

Jaya,
I don't understand your issue. The Philips watchdog can be programmed to
either provide an interrupt (your preferred method), or a reset
(Brendan's preferred method).  You are free to use the method of your
choice. Seems Philips have thought about it. 
Since there may also be external hardware (which also may potentially
get into a lockup state), connected to the /Reset line that is also
reset with a watchdog  I much prefer the "real" reset method. Sometimes
hardware is outside your choice, or you only discover issues late in the
piece and re-rolling a PCB is an expensive and time-costly option.
As you say, if choosing new hardware is an option open to you, maybe you
should choose a SAM or OKI and stop worrying about the LPC.
So far, despite a few documented minor software workarounds, I've been
happy with my choice of LPC2000 series. 
 
Cheers,
Bruce


[Non-text portions of this message have been removed]

jayasooriah wrote:
> I believe Philips has said its flash runs at 20MHz (or 25MHz I cannot
> remember).
> 
> This why I said LPC flash is no faster than SAM.

Your statement although allegedly quoting Philips is misleading as it 
lacks context or reference. You know and I know, as everyone else knows 
that the Philips flash is organized not 16 bits wide, nor 32 bits wide, 
but 128 bits wide, and in two interleaved banks!. That is 128 bits 
@20Mhz or whatever exact speed it is which means in most cases 32-bits 
@80Mhz.

Hitex's Insider's Guide www.hitex.co.uk/arm provides a lot of insight 
into the Philip's ARM implementation.

BTW, I am very tired of all this Philips bashing and the long long 
threads. I personally do not have a problem with Philips or the LPC 
part. As members of this group we can stand back and criticize something 
that in reality will always be imperfect or we can stand up and see the 
good in it and make it or the situation better (that's called being 
constructive).

By way of illustration, if you managed to design a complex chip, do you 
think it would be perfect? I am sure that no matter how well it was 
designed there would still be detractors and always will. Choose which 
you want to be.

The other option is simply to leave and move on as you propose....

*Peter*

At 02:06 AM 5/1/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> > I prefer that the device get back to a known good state as soon as
> > possible.  Keeping the output in the (possibly bad) state it was in is
> > definitely the last thing I want in that eventuality.  That can be
>done in
> > SW but it does increase the latency.
>
>If your software is in deadlock, and output is in bad state, and you
>want to set it back, it would take you no more than a few microseconds.
>
>What is your watchdog timeout?  Milliseconds?  Seconds?  What is a few
>microsecond latency in comparision?
>
>Would you still say latency is an issue?

Seconds is way too long.  Mostly I agree with you but there is a certain 
comfort in not having to rush around resetting I/O but instead deal with 
other setup issues.  As I said earlier it's unlikely this would be a 
deciding factor for me in choosing micros.

>As for other processers doing this, sure it is okay to do this if
>there are no ill side effects.  In the case of LPC we know there are
>ill side effects.

Only if you use a variant with an external bus and try to use boot0 and 
boot1 as I/O. I don't think using the boot lines as I/O is a good idea, but 
that doesn't make the watchdog bad.  You do have the choice here as how to 
implement the system  It's up to you to do so and part of that is handling 
the reset sources properly including dealing with how I/O is dealt 
with.  Yes there could be a few more warnings in the user manual and data 
sheets.

>I had to use watchdog on COP8 processor once in telephone hardare to
>meet failsafe requrements.  It was not acceptable if the current call
>in progress was interrupted by a failsafe recovery triggered by the
>watchdog timer.

Different system, different requirements.

>Any procesor that does a full reset will not meet such requirements.

Which means that the LPC, the ST10 and many other processors won't meet 
those requirements.  In those circumstances you choose a different micro.

I'm not saying the LPC is a paragon among microcontrollers but neither is 
it irredeemable.  Most of the features you are spending so much energy 
decrying are commonplace on other microcontrollers. Dealing with them is 
common practice in this field.

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/

--- In lpc2000@yahoogroups.com, "Bruce Paterson" <bruce.paterson@...>
> Jaya,
> I don't understand your issue. The Philips watchdog can be programmed to
> either provide an interrupt (your preferred method), or a reset
> (Brendan's preferred method).

Watchdog is typically used to recover from deadlocks that include the
shutdown of interrupts.

> You are free to use the method of your
> choice. Seems Philips have thought about it. 
> Since there may also be external hardware (which also may potentially
> get into a lockup state), connected to the /Reset line that is also
> reset with a watchdog  I much prefer the "real" reset method.

The SAM allows you to do this as a matter of choice.

> Sometimes
> hardware is outside your choice, or you only discover issues late in the
> piece and re-rolling a PCB is an expensive and time-costly option.
> As you say, if choosing new hardware is an option open to you, maybe you
> should choose a SAM or OKI and stop worrying about the LPC.
> So far, despite a few documented minor software workarounds, I've been
> happy with my choice of LPC2000 series. 

I do not disagree with that at all.  That is why it is possible for
one to be working on LPC and for this reason I tend to frown on "if
you do not like the LPC switch to another forum" kind of remarks.

Jaya

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:

> Your statement although allegedly quoting Philips is misleading as it 
> lacks context or reference. You know and I know, as everyone else knows 
> that the Philips flash is organized not 16 bits wide, nor 32 bits wide, 
> but 128 bits wide, and in two interleaved banks!. That is 128 bits 
> @20Mhz or whatever exact speed it is which means in most cases 32-bits 
> @80Mhz.

In its original response to the MAM problem Philips said that if the
MAM is used, instructions execute with zero wait states at up to 25Mhz
(it may have been 20MHz)

The SAM says its flash allows instructions to execute with zero wait
states up to 30 MHz.

I was just trying to point out that I did not see anything special in
LPC flash other than how it is marketed -- using optimum figures
compared to guaranteed figures by ATMEL.

> BTW, I am very tired of all this Philips bashing and the long long 
> threads. I personally do not have a problem with Philips or the LPC 
> part. As members of this group we can stand back and criticize
something 
> that in reality will always be imperfect or we can stand up and see the 
> good in it and make it or the situation better (that's called being 
> constructive).

I too am tired of how even the casual critique LPC is turned into a
bashing war.  As I said before, I am sure (and I know many as a matter
of fact) who are happy with the LPC for what they are doing.

Jaya

--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@...> wrote:

> Your statement although allegedly quoting Philips is misleading as it 
> lacks context or reference. You know and I know, as everyone else knows 
> that the Philips flash is organized not 16 bits wide, nor 32 bits wide, 
> but 128 bits wide, and in two interleaved banks!. That is 128 bits 
> @20Mhz or whatever exact speed it is which means in most cases 32-bits 
> @80Mhz.

The reference I was referring to appears at Philips site has been
moved and I do not know where to.  Here is what was there (from a
cached site):

<quote>

Q: Why does the code run slowly from flash when Philips claims that
the chip runs with nearly zero wait states from flash?

A: On reset, the Memory Accelerator Module (MAM) is disabled but the
MAM Timing register has a reset value of 0x7, which means that 6 wait
states are inserted for every flash access. You need to set it
depending upon the frequency at which you are running. If you are
running your application below or at 20 MHz you can set this register
to 0x1, which implies no wait states

</quote>

Do a google search on '"nearly zero" 20 MHZ LPC' and this is the first
hit shoudl give you the orignal URL relating to Philips Education and
Training for LPC2000 series.

The same information also appeared in a bug report by Philips Apps in
another forum but I cannot seem to find it now.  I know I read it, and
from memory, it said 25MHz not 20MHZ as the guaranteed instruction
rate when MAM is diasbled.

It says that LPC flash is 20MHz worst case, and I know SAM is faster
at 30MHz worst case.  I do not know about OKI flash speed but I
suspect it is in similar order of magnitute.

These things only come up when you look at comparison charts, and what
I am alluding some forum members is to look beyond anecodotal evidence
or promotional material.

I must say I find the kind of request to prove each and every bit of
trivia (that I thought were reasoble) very distracting and counter
productive.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> I must say I find the kind of request to prove each and every bit 
of
> trivia (that I thought were reasoble) very distracting and counter
> productive.
> 

The reason you were picked up on your statement is because it is 
completely misleading to quote the speed of the raw flash.

You might was well say the fastest you can run the LPC2xxx is 20MHz. 
This is true by your standards. However, Philips provide a PLL that 
allows you to run it at 60MHz (or whatever the current max rating 
is). In the same way, Philips provide the MAM to allow you to access 
the flash at a much faster rate.

Are you corrent in your direct statements? yes!

Are they misleading? yes!

Are they relevant? no!

As long as you continue to put forward misleading statements on this 
forum, people will point this out. If it annoys you, the simple fix 
is for you to stop doing it.

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> You might was well say the fastest you can run the LPC2xxx is 20MHz. 
> This is true by your standards. However, Philips provide a PLL that 
> allows you to run it at 60MHz (or whatever the current max rating 
> is). In the same way, Philips provide the MAM to allow you to access 
> the flash at a much faster rate.

Have a look what the others provide by way of speed ups before you
shoot yourself in the foot like this.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

> I think you seem to miss my point: that if you find a vendor produces
> devices that lockup or do not function properly (like the UART in
> LPC), the costs of trying to find the bugs and working around (if 
this
> is possible) are more than moving on to a processor with peripherals
> that have a good track record.
> 

You've now made the same point yet again, and still don't seem to 
understand the one I was making.

If I know there is a problem with a device, I can deal with it by 
designing around it, or as you suggest move onto another device.

Watchdog's are designed (amongst other things) to recover from  
unknown or unpredicted problems. By definition, I can't be aware of 
these beforehand to allow me to "move on" as you put it.

There is a risk that some peripheral in the device has the previously 
undiscovered characteristic of getting locked into a state 
unrecoverable by software. Hence my preference for a hardware-like 
reset into a known condition when a watchdog expires. That's all I was 
and am saying. 

There's no need to repeat your own point again: five times is more 
than enough!

Brendan

More misleading and bizarre statements with regard to fundamental 
facts.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@> wrote:
> >
> > I only
> > need simple features:
> > - Reliable Code Read Protection.

> The designs I have seen where client does not want the product 
cloned
> by copying hardware and the software, especially when software is 
the
> value item, do not use LPCs.  AVRs seem to be the popular choice.


This is misleading. To their credit ATMEL AVRs were the first in with 
an easily usable 'library' software to support updating firmware that 
has been encrypted. Microchip now have encryption libraries for PIC 
firmware.

ATMEL also makes its easier not to stuff up through the use of 'boot 
sectors' and relocatable interrupt destinations in the AVR.

None of these make AVRs interpedently more or less secure with regard 
to code read protection and there is nothing which prevents 
equivalent end functionality in other processors.

Hardware copying cannot be stopped, unless part ids are removed.

> 
> As for flash speed, I understand LPC is not as fast as SAM and maybe
> even OKI.  Have a look at guaranteed speeds and write/erase times.  
I
> dont know why you consider LPC flash as fastest.

This is bizarre. It is well known and accepted execution from flash 
is 'fast' in LPCs. The MAM is a well publicised feature of the LPC.

To quote from the manual:

"Simply put, the Memory Accelerator Module (MAM) attempts to have the 
next ARM instruction that will be needed in its latches in time to 
prevent CPU fetch stalls."

While flash speed maxes out, Philips made a clever decision to allow  
more flash contents (128 bits) to be grabbed than required 
immediately, while not implementing a full featured cache.

> The other reason to stay away from LPC flash is that it is in its
> infant stage -- there are a number of implementation bugs to be 
ironed
> out before it becomes as usable like other flash architectures.  At
> the moment it is good for OTP needs but with the advantage that 
field
> upgrades are possible.
> 
> Jaya
>

To suggest that Philips sells products with infant stage flash just 
beggars belief.

To also suggest there is even a remote hint on consensus of this is 
irresponsible.

John Heenan

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
> Watchdog's are designed (amongst other things) to recover from  
> unknown or unpredicted problems. By definition, I can't be aware of 
> these beforehand to allow me to "move on" as you put it.

My textbook and processor manuals say the watchdogs in CPUs are
designed to enable recovery from software deadlocks.

If you have hardware deadlocks, and need to recover from these, you
have need a watchdog that is external to the system that deadlocks.

Jaya

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
> > As for flash speed, I understand LPC is not as fast as SAM and maybe
> > even OKI.  Have a look at guaranteed speeds and write/erase times.  
> > I dont know why you consider LPC flash as fastest.
> 
> This is bizarre. It is well known and accepted execution from flash 
> is 'fast' in LPCs. The MAM is a well publicised feature of the LPC.
> 
> To quote from the manual:
> 
> "Simply put, the Memory Accelerator Module (MAM) attempts to have the 
> next ARM instruction that will be needed in its latches in time to 
> prevent CPU fetch stalls."
> 
> While flash speed maxes out, Philips made a clever decision to allow  
> more flash contents (128 bits) to be grabbed than required 
> immediately, while not implementing a full featured cache.

As I said, comparison tables tend to give a more realistic picture

I have compared raw flash speed (before cache or MAM) on SAM with LPC
and the values are SAM=30MHz vs LPC=20MHz.

Lets look at erase speeds: SAM=6ms (page) and 15ms (full) vs LPC=400ms
Big difference if you need to use flash to store data at run time.

I read promotional literature.  But I tend to look at figures i can
compare and the difference between MAM and tractional caching is that
straighforward.

The beauty of benchmarks (like statistics) is that they predict the
likely outcome, but never tell you the actual outcome for a particular
case.

I have written C code make GCC look better *and* worse than another
compiler.  I know first hand what goes on in producing promotional
literature.  I think most people do.

If you assume whatever the manual says is the whole truth, it should
come as no surprise to you that that you consider that product in it
best light.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
> Have a look what the others provide by way of speed ups before you
> shoot yourself in the foot like this.
>

Can you explain how me pointing out that comparing raw flash speeds is 
misleading and irrelevant is "shooting myself in the foot"?

I've already pointed out that the comparison I'd use is to conduct 
benchmarks relevant to the application that include whatever speed up 
mechanisms (MAM etc.) provided.

If you think there's a better way, I'd be interested to hear it.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> Lets look at erase speeds: SAM=6ms (page) and 15ms (full) vs 
LPC=400ms
> Big difference if you need to use flash to store data at run time.
> 

Philips describe the on-board flash as "program memory", which is 
its intended purpose. The fact that you can use it for run-time data 
storage is a handy-to-have additional and optional feature.

As you've pointed out (ad nauseum) the flash is optimised for 
program storage and not for data storage. Hence the odd block sizes, 
relatively low erase times etc. 

It is however optimised for program speed of execution, which most 
(all?) benchmarks will show.

This isn't a design flaw, it's a design to fit-the-purpose. As you 
yourself recently pointed out, it's more than adequate for OTP with 
the ability to upgrade, which is what it's intended to do. I'd be 
interested to hear any example of another comparable device that 
exceeds it in performance for program execution from flash.

Brendan

>> Lets look at erase speeds: SAM=6ms (page) and 15ms (full) vs LPC=400ms
>> Big difference if you need to use flash to store data at run time.

I don't think that is the whole story.  The 400mSec for the LPC is due to a
voltage convertor starting up inside the chip, as I recall.  It is not a
function of flash memory speed.  Perhaps the SAM part keeps a voltage
convertor running all the time inside.  I do not know.  But I use IAP in my
designs with the LPC.  Works great.

Chris.

--- In lpc2000@yahoogroups.com, <sig5534@...> wrote:

> I don't think that is the whole story.  The 400mSec for the LPC is
due to a
> voltage convertor starting up inside the chip, as I recall.  It is not a
> function of flash memory speed.

I think so too and the two registers that control this converter are
labelled as LPC[10] and LPC[11] in my boot loader page.

Whether it is flash or converter this is no consolation to a user.  I
know of one instance when the client thought Philips EEPROM example
was a good idea until they discovered interrupts they could not afford
to leave interrupts off for almost half a second.

You get what you pay for applies here and so long as it meets your
needs, there is no reason not be happy with it.

Jaya

Should designs allways follow textbooks or manuals of older processors?

Why have 2 watchdogs: internal & external, if one internal integrated
can watch both hardware & software. Integrated watchdog can be
designed functionally external to system it watches.

Designs I have worked with on my 25 years career on microprosessors
have often had tight size requirements and external components almost
allways cost also more than integrated features.

And I haven't yet seen a perfect design. All could have been made
better, if more money, time and better resources have been used, but
then they might have come too expensive or had been on market too late.
 
--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> > Watchdog's are designed (amongst other things) to recover from  
> > unknown or unpredicted problems. By definition, I can't be aware of 
> > these beforehand to allow me to "move on" as you put it.
> 
> My textbook and processor manuals say the watchdogs in CPUs are
> designed to enable recovery from software deadlocks.
> 
> If you have hardware deadlocks, and need to recover from these, you
> have need a watchdog that is external to the system that deadlocks.
> 
> Jaya
>