Lpc2000

I am thinking of using an LPC22xx as a single chip micro in an 
industrial controller board.  2 questions.  I assume the device can 
be used to count external pulses, encoder signal, which pin(s) can be 
used for a counter i/p?  
The LPC2xxx's supposedly have a built in RTC?  Anyone got any info on 
connecting a battery or super cap to maintain the RTC contents during 
power down?

Hi ,

> industrial controller board.  2 questions.  I assume the device can 
> be used to count external pulses, encoder signal, which pin(s) can be 
> used for a counter i/p?  

The Timers have capture/compare channels, but I haven't looked yet at
counting pulses with it.
With "encoder signal", do you mean you need to input a quadrature signal
(eg. from a shaft encoder) to the LPC2000 ?
That's one thing missing from the LPC2000. I haven't seen too many MCUs
that had that capability built into its timers. 
(Super H was one of the few, off-the-cuff)

-- Kris

No, dont need quadrature decoder.  Just a simple counter input to 
count pulses.  Capture inputs (normally) are only good for timing the 
length of a  signal.




--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi ,
> 
> > industrial controller board.  2 questions.  I assume the device 
can 
> > be used to count external pulses, encoder signal, which pin(s) 
can be 
> > used for a counter i/p?  
> 
> The Timers have capture/compare channels, but I haven't looked yet 
at
> counting pulses with it.
> With "encoder signal", do you mean you need to input a quadrature 
signal
> (eg. from a shaft encoder) to the LPC2000 ?
> That's one thing missing from the LPC2000. I haven't seen too many 
MCUs

> that had that capability built into its timers. 
> (Super H was one of the few, off-the-cuff)
> 
> -- Kris

At 07:38 AM 3/2/04 +1100, you wrote:
>Hi ,
>
> > industrial controller board.  2 questions.  I assume the device can
> > be used to count external pulses, encoder signal, which pin(s) can be
> > used for a counter i/p?
>
>The Timers have capture/compare channels, but I haven't looked yet at
>counting pulses with it.

You can't, at least on the variants that I've looked at.  This is one of 
the odder lacks on the chips from my perspective [others have their own 
choices ;) ].  I'd have gladly traded off the RTC for more timer 
resources.  The little RTC functionality I have any use for can be easily 
done with timers and since there is no timer supply separate from the CPU 
supply....

I must admit I really don't see the point of the RTC on the LPC it's only 
purpose seems to be to save a little arithmetic.

>With "encoder signal", do you mean you need to input a quadrature signal
>(eg. from a shaft encoder) to the LPC2000 ?
>That's one thing missing from the LPC2000. I haven't seen too many MCUs
>that had that capability built into its timers.

I've seen a few, it's more common on DSPs though.  Quadrature is fairly 
easily converted to pulse + direction though and more micros support that 
(eg ST10/C166, 196, some Motorola parts if I remember correctly).

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

Forget the RTC.  It is only useful when the system has been initialized
and running.

-Bill Knight
R O SoftWare


On Mon, 01 Mar 2004 20:34:13 -0000, onceinfour wrote:

I am thinking of using an LPC22xx as a single chip micro in an 
industrial controller board.  2 questions.  I assume the device can 
be used to count external pulses, encoder signal, which pin(s) can be 
used for a counter i/p?  
The LPC2xxx's supposedly have a built in RTC?  Anyone got any info on 
connecting a battery or super cap to maintain the RTC contents during 
power down?





Yahoo! Groups Links

I understand,

I don't think you can count pulses thru a capture channel. The only thing of
course
is to use an External Int, and to maintain a counter in SW, but I'm sure
you have reasons why you can't do it that way, besides, any MCU can do
that...
The CapComp structure of the Timers could actually do with a bit more
versatility !

B regards,
Kris

> No, dont need quadrature decoder.  Just a simple counter input to
> count pulses.  Capture inputs (normally) are only good for timing the
> length of a  signal.

--- In lpc2000@yahoogroups.com, "onceinfour" <mmack287@h...> wrote:
> I am thinking of using an LPC22xx as a single chip micro in an 
> industrial controller board.  2 questions.  I assume the device can 
> be used to count external pulses, encoder signal, which pin(s) can
be 
> used for a counter i/p?  
> The LPC2xxx's supposedly have a built in RTC?  Anyone got any info
on 
> connecting a battery or super cap to maintain the RTC contents
during 
> power down?

I took a look at the specs concerning this and I don't think it will
be overly practical.  The max current drain with *nothing* running
over temp is 0.5 mA.  Unless you are using a rechargable battery and
power will be supplied every day or at least week, this is rather
high.  The RTC in the LPC2x is not really setup for battery operation
since you have to power the whole chip to keep the clock going.  

There are two ways to deal with this.  

1) Use and external RTC.  These are not overly expensive.  Since you
need a power on reset, you can combine these two in one chip using
something like the SH3000 uBuddy from Semtech.  It can cut the clock
to the ARM and handles the whole POR/BOD issue as well as providing an
RTC and generates a high speed clock from the 32kH xtal.  Pretty cool
for a lot of apps where the CPU needs external devices like this. 

2) Use an ARM that provides a *real* battery backed RTC like the
AT91M55800A.  This guy has a separate RTC with a battery power input
and runs on 1-2 uA of current when the power is off.  It has a control
input and an output to let the RTC wake up the CPU and cut power when
it is not running.  Also pretty cool.  :)

--- In lpc2000@yahoogroups.com, "onceinfour" <mmack287@h...> wrote:
> I am thinking of using an LPC22xx as a single chip micro in an 
> industrial controller board.  2 questions.  I assume the device can 
> be used to count external pulses, encoder signal, which pin(s) can be 
> used for a counter i/p?  
> The LPC2xxx's supposedly have a built in RTC?  Anyone got any info on 
> connecting a battery or super cap to maintain the RTC contents during 
> power down?

Hi,

the 22xx (as well as the 21xx) do not feature counter inputs (yet) but
capture inputs to capture an internal free running timer. 

The RTC only runs when the device is at least in idle mode. In other
words, it is perfect for an application that is always connected to
power or to measure "work-hours" for what ever kind of machine. It is
not well suited for keeping time when the system is operated by a
battery and has significant "off-time" and the time reference should
be kept alive. Simply put, there is no 32-kHz input.

We are aware that we need to chance this. It will be implemented (both
counter inputs and 32-khz input on a device coming in fall 2004. 

Our team is very greatful for all the questions asked (and answered!)
here in this forum and rest assured that some of the answers are also
from us ;-)

Best regards from the Philips Apps Team.
p.s. I intend to post more "official statements" on this group in the
future.

At 10:17 PM 3/1/04 +0000, you wrote:
>words, it is perfect for an application that is always connected to
>power

Let me make sure I've got this straight.  It's perfect for creating a 
device that flashes 12:00 when the power comes back on? :^)

>or to measure "work-hours" for what ever kind of machine.

How can it be well suited to measure work hours if it loses track of time 
when it loses power?  In fact how is it any better than simply counting 
using one of the existing timers?

I have implemented such a feature before and I don't understand why you 
would want to complicate it by introducing an RTC.  I have seen RTCs that 
provide this as an additional feature but using an RTC just to implement it 
seems like overkill.

>We are aware that we need to chance this. It will be implemented (both
>counter inputs and 32-khz input on a device coming in fall 2004.

The counter sounds good.  Would it be too much to hope that it won't 
require large pinouts in order to get a counter?

I rather envision the RTC as a Dilbertian feature foisted upon the design 
by a marketing checklist.
    (  - We need an RTC
       + It won't give us any more capabilities
       - We need an RTC
       + The implementation we have won't be very useful
       - We need an RTC
       + OK, OK
       - We are getting complaints about the RTC
       + The sound of gritted teeth }


>Our team is very greatful for all the questions asked (and answered!)
>here in this forum and rest assured that some of the answers are also
>from us ;-)
>
>Best regards from the Philips Apps Team.
>p.s. I intend to post more "official statements" on this group in the
>future.

Good to hear from you.  If you are taking suggestions, might I suggest 
ditching the RTC in favour of other peripherals (more and more flexible 
timers as a for instance) :) ?

BTW, don't take too much of the above to heart but the implementation of 
the RTC on the LPC has always struck me as rather pointless.

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

> Our team is very greatful for all the questions asked (and answered!)
> here in this forum and rest assured that some of the answers are also
> from us ;-)
>
> Best regards from the Philips Apps Team.
> p.s. I intend to post more "official statements" on this group in the
> future.

Hello there,

It is certainly more reaasuring to see Philips' presence here.
I wonder if you would be able to describe more concisely when the code
protection
feature of LPC2000 is/will be introduced, and in just a few words what it
entails.
Hugh at Ashling has recently covered this, but this issue seemed to need
confirmation.
Are you able to alleviate any doubts/hesitations ?

Also, I am led to believe that die size / economy will restrict LPC2000 for
quite some
time to 16 K SRAM. Correct ?
Will we ever see > 16 K again ?

Best regards,
Kris
www.microbit.com.au

> From: "philips_apps" <philips_apps@...>

> ...

> Best regards from the Philips Apps Team.
> p.s. I intend to post more "official statements" on this group in the
> future.

Are you really from Philips? 

If so, why not have the courtesy to identify yourself (by name)?

Michael.

-snip--
> 
> Hello there,
> 
> It is certainly more reaasuring to see Philips' presence here.
> I wonder if you would be able to describe more concisely when the code
> protection
> feature of LPC2000 is/will be introduced, and in just a few words
what it
> entails.
> Hugh at Ashling has recently covered this, but this issue seemed to need
> confirmation.
> Are you able to alleviate any doubts/hesitations ?
----------------------------------------------------------
The protection (disabling JTAG) happens first thing at power up no
matter if protection is enabled or not. 
Then the bootloader checks whether the protection is supposed to be
enabled and enables the JTAG interface if the protection pattern is
not found in the corresponding memory location. 

This is a preliminary wording of future documentation:

Code Read Protection
--------------------
Code read protection is enabled by programming the flash address
location 0x1FC (User flash sector 0) with value 0x87654321 (2271560481
Decimal). Address 0x1FC is used to allow some room for the fiq
exception handler. When the code read protection is enabled the JTAG
debug port, external memory boot and the following ISP commands are
disabled.

Read Memory
Write to RAM
Go
Copy RAM to Flash
Write Port to RAM

The ISP commands mentioned above terminates with return code
CODE_READ_PROTECTION_ENABLED.
The ISP erase command only allows erasure of all user sectors (not
just one) when the code read protection is enabled. This limitation
does not exist if the code read protection is not enabled. IAP
commands are not affected by the code read protection.

Hope this helps.
-----------------------------------------------
> 
> Also, I am led to believe that die size / economy will restrict
LPC2000 for
> quite some
> time to 16 K SRAM. Correct ?
> Will we ever see > 16 K again ?
-------------------------------------------------------
Yes you will see more than 16k (32k to begin with) late fall this year. 

Best regards, Robert

Michael,

good question whether I am really from Philips or not. May be this
helps to convince at least you:

I sent your prototype Keil Board on Dec 3 from Sunnyvale, CA. If you
tried to use CAN, you found out that it does not work on the prototype
(works now) but you have not tried yet because I did not get any
inquiries either from you nor from C.H. your contact in the UK.

.......  any more details required?   ;-)

There is however a reason why I did not identify myself by name and
that is because "official statements" will be posted by different
members of our team and we want to post these statements as "Philips_Apps"

Regards, Robert

> Are you really from Philips? 
> 
> If so, why not have the courtesy to identify yourself (by name)?
> 
> Michael.

I am about to embark on my first LPC2106 project. I chose this product 
for its small size and cost for a single chip solution for a data logger.

I also need counters + RTC; I also need a low power consumption. I want 
10 years operation from a single lithium cell.

The intention is to feed the pulse inputs into D Flip flops (to catch 
them) and then feed them into interrupt inputs. The RTC will be handled
by an external component (probably a maxim chip) in the same way. I 
intend to keep the product in power down mode most of the time
(10 microamps I believe).  I would be interested in anyones comments on 
this use of the processor.

I was interested in Phiips comments about a new development with these 
components. Unfortunately I can't wait. If they are prepared to accept 
comments from us, then they could look at the PIC16F877 / PIC16F452. It 
has a rubbish processing core, but a great I/O system. I love the 
"interrupt on change" inputs. I have had these components, together with 
a whole board, operating at 25 microamps using the on board 32KHz 
oscillator. The  main clock wakes up every RTC interrupt (every second) 
and whenever an external event happens.I get full processing capablity 
with negligible power consumption. Pity about the processing core and 
it's innumerable silicon bugs, else I would be still using this series.

Owen Mooney

Owen,

the LPC2000 is a 32-bit family the PIC16xx is a 14-bit  ;-))  family.
Very different animals. Actually the PIC is nothing but an 8-bit micro
with a weird CPU as you already pointed out. If you want to look at
Philips, lowest power, similar I/O functions, similar processing power
:-|  you have to look at the LPC900 family, e.g. the LPC935 could be
very close to what you need. 
http://www.semiconductors.philips.com/pip/P89LPC935FDH.html
Unfortunately the max flash size is only 8k but it has a RTC-timer
(just a long timer, no time of day function) and if clocked with 32
kHz external the power consumption should be close to the 10 uA you
mentioned from the MAX part. You can switch to the internal 7.37..MHz
oscillator on the fly and get "ok" performance for the time you need.

May be this helps.

For lowest power consumption the MSP430 offers interesting features!

Cheers Bob

--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> I am about to embark on my first LPC2106 project. I chose this product 
> for its small size and cost for a single chip solution for a data
logger.
> 
> I also need counters + RTC; I also need a low power consumption. I want 
> 10 years operation from a single lithium cell.
> 
> The intention is to feed the pulse inputs into D Flip flops (to catch 
> them) and then feed them into interrupt inputs. The RTC will be handled
> by an external component (probably a maxim chip) in the same way. I 
> intend to keep the product in power down mode most of the time
> (10 microamps I believe).  I would be interested in anyones comments on 
> this use of the processor.
> 
> I was interested in Phiips comments about a new development with these 
> components. Unfortunately I can't wait. If they are prepared to accept 
> comments from us, then they could look at the PIC16F877 / PIC16F452. It 
> has a rubbish processing core, but a great I/O system. I love the 
> "interrupt on change" inputs. I have had these components, together
with 

> a whole board, operating at 25 microamps using the on board 32KHz 
> oscillator. The  main clock wakes up every RTC interrupt (every second) 
> and whenever an external event happens.I get full processing capablity 
> with negligible power consumption. Pity about the processing core and 
> it's innumerable silicon bugs, else I would be still using this series.
> 
> Owen Mooney

Owen Mooney wrote:
> I am about to embark on my first LPC2106 project. I chose this product
> for its small size and cost for a single chip solution for a data logger.
> I also need counters + RTC; I also need a low power consumption. I want
> 10 years operation from a single lithium cell.
> The intention is to feed the pulse inputs into D Flip flops (to catch
> them) and then feed them into interrupt inputs. The RTC will be handled
> by an external component (probably a maxim chip) in the same way. I
> intend to keep the product in power down mode most of the time
> (10 microamps I believe).  I would be interested in anyones comments on
> this use of the processor.

The LPC2000s are great processors but I think you should look at something
like the MSP430 range for this type of application. The LPCs are fast and
are capable of low-power operation, but it sounds like you need micro-power
operation. 

> I was interested in Phiips comments about a new development with these
> components. Unfortunately I can't wait. If they are prepared to accept
> comments from us, then they could look at the PIC16F877 / PIC16F452. It
> has a rubbish processing core, but a great I/O system. I love the
> "interrupt on change" inputs. I have had these components, together with
> a whole board, operating at 25 microamps using the on board 32KHz
> oscillator. The  main clock wakes up every RTC interrupt (every second)
> and whenever an external event happens.I get full processing capablity
> with negligible power consumption. Pity about the processing core and
> it's innumerable silicon bugs, else I would be still using this series.

Once again the MSP430s can run straight off a 32KHz rock, and have the
"interrupt on change" thing on all individual pins on ports P1 and P2. In
terms of power consumption the MSP430F149 draws 2.5uA at 4Khz (32K rock) at
2.2V.

I'm saying all this about the MSP430 because I don't understand why you are
considering buying a sports car when you really want a motor-scooter. The
LPC2106 is a great processor but don't go trying to fit a square peg into a
round hole, you'll only frustrate yourself.

BTW, please don't mention that P-I-C word in this group, it's an anathema
and you shouldn't go speaking like that! ;)


- Peter Jakacki

Hi Robert,

> The protection (disabling JTAG) happens first thing at power up no
> matter if protection is enabled or not.
> Then the bootloader checks whether the protection is supposed to be
> enabled and enables the JTAG interface if the protection pattern is
> not found in the corresponding memory location.
>
> This is a preliminary wording of future documentation:

That makes sense, simple and nifty !
Can you confirm wihich devices onward this will be implemented on ?

> Yes you will see more than 16k (32k to begin with) late fall this year.

Great news.
We're kinda spoiled with LPC2106's 64 K, and it makes for really fast
debugging
compared to Flashing.
My main application, the BASIC interpeter with RF frontend ideally has 32 -
64 K
RAM on-chip. To keep PCB cost low, it's much better not to have busses
around
vis-a-vis EMI. It's a bugger to keep it out of IF strips in transceivers
unless you
can throw away several layers like it's out of fashion anyway.


B regards,
Kris

> Michael,
> 
> good question whether I am really from Philips or not. May be this
> helps to convince at least you:
...
> Regards, Robert

Welcome, Robert,

Very glad to see that you will be contributing to these discussions.

Michael.

> I am about to embark on my first LPC2106 project. I chose this product
> for its small size and cost for a single chip solution for a data logger.
> I also need counters + RTC; I also need a low power consumption. I want
> 10 years operation from a single lithium cell.

See: rtc_smps_lpc2k.pdf in Files section of this group.
This is just simple schematic that I designed [took me 5 minutes :)] to show
you one possible approach to this application.

When SMPS is in shutdown, total power consumption is not more than 2uA with
RTC working.

You can wake-up LPC with Enter button or with RTC interrupt. As soon as that
happens you need to drive PWRCTRL in order to have SMPS working just as long
as you need it. Then, check both Enter and PCF to see what caused wake-up.
When you want to shutdown again, release PWRCTRL.

When in shutdown LPC (and other circuits) are disconnected from battery so
voltage is 0V (true output disconnect).

If you decide to go to powerdown mode with LPC it's OK since SMPS has only
85uA quiescent current so, again, you have minimum power consumption.

This is as "low power" as it gets with LPC and battery with voltage lower
than 3V :) Even if it is not suitable for your application, you might find
this schematic useful - I hope :)

Regards,
Igor

P.S.
You could use P-I-C for your application, too ;)

Hi Kris,

good news and bad news about protection. Let's get the bad news out of
the way. The LPC2104/5/6 can not be upgraded with protection as the
design is done :-( 

Good news:
A block that is handling pin assignments is used in all the 64-pin and
144-pin devices for the protection feature. All 144-pin devices that
are coming from volume production (if you have them already they are
still samples, volume production devices are in the fab right now)
will have the protection feature.

64-pin devices can be protected but what is out there in the field
today does not have the protection (e.g. parts on the evaluation
boards from Keil). Will keep this forum posted as soon as the
protection is implemented on the 64-pin devices.

Regards, Robert

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Robert,
> 
> > The protection (disabling JTAG) happens first thing at power up no
> > matter if protection is enabled or not.
> > Then the bootloader checks whether the protection is supposed to be
> > enabled and enables the JTAG interface if the protection pattern is
> > not found in the corresponding memory location.
> >
> > This is a preliminary wording of future documentation:
> 
> That makes sense, simple and nifty !
> Can you confirm wihich devices onward this will be implemented on ?
> 
> > Yes you will see more than 16k (32k to begin with) late fall this
year.
> 
> Great news.
> We're kinda spoiled with LPC2106's 64 K, and it makes for really fast
> debugging
> compared to Flashing.
> My main application, the BASIC interpeter with RF frontend ideally
has 32 -

> 64 K
> RAM on-chip. To keep PCB cost low, it's much better not to have busses
> around
> vis-a-vis EMI. It's a bugger to keep it out of IF strips in transceivers
> unless you
> can throw away several layers like it's out of fashion anyway.
> 
> 
> B regards,
> Kris

Thanks for your replies.

No I don't want a lesser processor according to a couple of suggestions! 
I want some grunt here! I have some real work to do. My main reason for 
mentioning the PIC (sorry Peter) was that some of the I/O structures 
were good. I still hope to make the micropower device out of this processor.

Owen

Hello, Robert.

On the topic of protection, I just want to throw this out as
a cautionary note.  The method of code protection that Philips
is proposing for the LPC family looks good, but I see at least
one good attack on it.  Namely, a trojan horse.

Since the programming firmware is not to be touched by the
normal programmer/developer, we're prone to not even look at
it.  A clever attacker could take a target system, blank the
chip, load in new code which overwrites the boot code provided
by Philips.  Such a design will require reading and understanding
the Philips code and designing a reasonable substitute.  The
difference would be that it would only act like it prevented
readback of code after protection was set.  Via some special
sequence, the boot code would read out the FLASH.

So, the attack goes:
1) but the target device
2) blank and reprogram the flash
3) return it as broken and ask for it to be reprogrammed (may
   require some social engineering)
4) send it back and let them reprogram it
5) receive 'fixed' unit and read out FLASH with special sequence.

So, when repairing failed units, you may want to take an extra
step to ensure that this kind of attack hasn't occured--load
in a quick program that does a checksum on the bootblock and
gives back a thunbs up/down indication of tampering.

Also, this kind of attack could be launched through a supply
chain.  Be careful who you buy your chips from and where they
get them from.

This just crossed my mind as I was drifting off to sleep last
night, so I thought I'd share it so that it doesn't have to
keep anyone else up.

Cheers,
David

Hi David, Robert et al,

It is interesting that a thread has been in progress about code security
on MSP430 forum.
I personally found this very interesting reading :
(Thanks to Chris Liechti who posted it on Y! MSP430)
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html

Mininal code security I deem paramount, to turn away (hopefully) most
prospective firmware pirates. For about 7 years now, every client I have
developed for always wanted code security. (or the perception of it)

A product that benefits greatly from a small form factor, low power,
while high CPU thruput like LPC2000, surely to me implies that there's a
good
chance the surrounding HW in product XYZ is fairly minimal, therefore easily
copied.

-- Kris

David Willmore wrote :

> Hello, Robert.
>
> On the topic of protection, I just want to throw this out as
> a cautionary note.  The method of code protection that Philips
> is proposing for the LPC family looks good, but I see at least
> one good attack on it.  Namely, a trojan horse.
>
> Since the programming firmware is not to be touched by the
> normal programmer/developer, we're prone to not even look at
> it.  A clever attacker could take a target system, blank the
> chip, load in new code which overwrites the boot code provided
> by Philips.  Such a design will require reading and understanding
> the Philips code and designing a reasonable substitute.  The
> difference would be that it would only act like it prevented
> readback of code after protection was set.  Via some special
> sequence, the boot code would read out the FLASH.
>
> So, the attack goes:
> 1) but the target device
> 2) blank and reprogram the flash
> 3) return it as broken and ask for it to be reprogrammed (may
>    require some social engineering)
> 4) send it back and let them reprogram it
> 5) receive 'fixed' unit and read out FLASH with special sequence.
>
> So, when repairing failed units, you may want to take an extra
> step to ensure that this kind of attack hasn't occured--load
> in a quick program that does a checksum on the bootblock and
> gives back a thunbs up/down indication of tampering.
>
> Also, this kind of attack could be launched through a supply
> chain.  Be careful who you buy your chips from and where they
> get them from.
>
> This just crossed my mind as I was drifting off to sleep last
> night, so I thought I'd share it so that it doesn't have to
> keep anyone else up.
>
> Cheers,
> David
>
>