2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Does anyone have any code examples of how I can use a LPC2138 to detect 
the width of the positive pulse in a PWM signal. I know I can use the 
timer circuit and detect the rising and falling edges do some math and 
determine the width. I am very new to micro controllers and some code 
examples or guidance would be greatly appreciated.

Thanks
J Parham
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi J,

> Does anyone have any code examples of how I can use a LPC2138 to detect
> the width of the positive pulse in a PWM signal. I know I can use the
> timer circuit and detect the rising and falling edges do some math and
> determine the width. I am very new to micro controllers and some code
> examples or guidance would be greatly appreciated.

For some theory take a look at this Atmel application note:
AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages, revision
A, updated 10/05)
Found here: http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

As for the LPC2100 you would use the Capture feature of the Timer
peripheral.  Setup timer to generate an interrupt on capture pin leading or
trailing edge.  In the interrupt routine read the capture register value and
pass it on to your algorithm.  

Be sure to read the correct section of the errata sheet related to TIMER.
	Joel
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I recently implemented pulse width measurement on an LPC2124 to detect
the width of pulses from an R/C radio receiver (varies between 1ms and
2ms positive-going pulse width) for a theatrical motion control and
lighting control project.  There's an interesting shortcoming that I
encountered, each capture pin can only capture a rising or falling
edge, but not both.  So to measure pulse width, I found it necessary
to use *two* capture pins tied together, one to capture the rising
edge and another to capture the falling edge.  The main loop of the
program compares the two, and if the count on the falling edge capture
is larger than the count on the rising edge capture, then pulse_width
= falling_edge_capture - rising_edge_capture.

The Hitex book includes an example whose description says it measures
a pulse width, but the example shown (using one capture pin) very
clearly does not measure pulse width and is incomplete, and merely
measures the time between pulses (but not the pulse width).  Now my
curiosity is had, has anyone succeeded in measuring pulse widths
without using multiple capture pins?  From the way the LPC capture
units are set up, I doubt it's possible, short of flipping the capture
edge polarity in an ISR.  ISR-based solutions are only really useful
if the pulse width is larger than the execution time of the ISR + any
interrupt latency due to other ISR's executing at the time.

-Ryan
	--- In lpc2000@lpc2..., "Joel Winarske" <joelw@...> wrote:
>
> Hi J,
> 
> > Does anyone have any code examples of how I can use a LPC2138 to
detect
> > the width of the positive pulse in a PWM signal. I know I can use the
> > timer circuit and detect the rising and falling edges do some math and
> > determine the width. I am very new to micro controllers and some code
> > examples or guidance would be greatly appreciated.
> 
> For some theory take a look at this Atmel application note:
> AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages,
revision
> A, updated 10/05)
> Found here:
http://www.atmel.com/dyn/products/app_notes.asp?family_id=607
> 
> As for the LPC2100 you would use the Capture feature of the Timer
> peripheral.  Setup timer to generate an interrupt on capture pin
leading or
> trailing edge.  In the interrupt routine read the capture register
value and
> pass it on to your algorithm.  
> 
> Be sure to read the correct section of the errata sheet related to
TIMER.
>  
> 
> Joel
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The 'standard' way to do this is to use 1 pin. ISR latency on slow small 
micros is usually more than fast enough. On an LPC it should be a shoe 
in. 1 instruction cycle to flip the bit sense. How hard can it be. A 
typical ISR to measure pulse width on most micros requires fewer than 10 
instructions. Your final sentence may be true, but this is the case in 
99% of applications, and is certainly true in your case, even with the 
comparatively poor interrupt latency of the LPC2xxx. On the odd 
occasions where the pulses are too fast I would suggest that using two 
pins is a poor solution anyway, since the resolution of meaurement will 
only be typically 2-4 bits at most, and other solutions would offer a 
better result.

Cheers

Al

Ryan Niemi wrote:

>I recently implemented pulse width measurement on an LPC2124 to detect
>the width of pulses from an R/C radio receiver (varies between 1ms and
>2ms positive-going pulse width) for a theatrical motion control and
>lighting control project.  There's an interesting shortcoming that I
>encountered, each capture pin can only capture a rising or falling
>edge, but not both.  So to measure pulse width, I found it necessary
>to use *two* capture pins tied together, one to capture the rising
>edge and another to capture the falling edge.  The main loop of the
>program compares the two, and if the count on the falling edge capture
>is larger than the count on the rising edge capture, then pulse_width
>= falling_edge_capture - rising_edge_capture.
>
>The Hitex book includes an example whose description says it measures
>a pulse width, but the example shown (using one capture pin) very
>clearly does not measure pulse width and is incomplete, and merely
>measures the time between pulses (but not the pulse width).  Now my
>curiosity is had, has anyone succeeded in measuring pulse widths
>without using multiple capture pins?  From the way the LPC capture
>units are set up, I doubt it's possible, short of flipping the capture
>edge polarity in an ISR.  ISR-based solutions are only really useful
>if the pulse width is larger than the execution time of the ISR + any
>interrupt latency due to other ISR's executing at the time.
>
>-Ryan
>
>
>--- In lpc2000@lpc2..., "Joel Winarske" <joelw@...> wrote:
>  
>
>>Hi J,
>>
>>    
>>
>>>Does anyone have any code examples of how I can use a LPC2138 to
>>>      
>>>
>detect
>  
>
>>>the width of the positive pulse in a PWM signal. I know I can use the
>>>timer circuit and detect the rising and falling edges do some math and
>>>determine the width. I am very new to micro controllers and some code
>>>examples or guidance would be greatly appreciated.
>>>      
>>>
>>For some theory take a look at this Atmel application note:
>>AVR135: Using Timer Capture to Measure PWM Duty Cycle   (12 pages,
>>    
>>
>revision
>  
>
>>A, updated 10/05)
>>Found here:
>>    
>>
>http://www.atmel.com/dyn/products/app_notes.asp?family_id=607
>  
>
>>As for the LPC2100 you would use the Capture feature of the Timer
>>peripheral.  Setup timer to generate an interrupt on capture pin
>>    
>>
>leading or
>  
>
>>trailing edge.  In the interrupt routine read the capture register
>>    
>>
>value and
>  
>
>>pass it on to your algorithm.  
>>
>>Be sure to read the correct section of the errata sheet related to
>>    
>>
>TIMER.
>  
>
>> 
>>
>>Joel
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> measures the time between pulses (but not the pulse width).  Now my
> curiosity is had, has anyone succeeded in measuring pulse widths
> without using multiple capture pins?  From the way the LPC capture

Yes.  I have a design using six capture inputs doing bit banged CAN bus on
the LPC214x.  Polarity is being conditionally flipped in ISR.  It's been
rock solid.  

If IRQ latency is a problem, and timing permits you can always implement as
FIQ.
	Joel
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> > measures the time between pulses (but not the pulse width).  Now my
> > curiosity is had, has anyone succeeded in measuring pulse widths
> > without using multiple capture pins?  From the way the LPC capture
> 
> Yes.  I have a design using six capture inputs doing bit banged CAN bus on
> the LPC214x.  Polarity is being conditionally flipped in ISR.  It's been
> rock solid.

I should mention it uses one capture pin per bus.
	Joel
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Al,

You're right in most circumstances. However, anyone reading this 
needs to be aware that the LPC2xxx parts, like many other 32-bit 
micros with pipelined architectures and multiple (internal) buses, 
are not quite as straightforward as previous generation micros. For 
example, the "1 instruction cycle to flip the bit sense" you refer to 
will actually take multiple clocks, due to the latency of the 
peripheral bus.

Interrupt latency is also not straightforward to work out, as it will 
include some or all of:

- delay to due to background software disabling interrupts
- variable instruction execution delay (ARM is not very "RISC" like 
in this respect, due to extended instructions such as load multiple)
- variable hardware interrupt acknowledgement delay
- software delay in saving additional context and calling correct ISR

If your interrupt software isn't set up to handle nested interrupts, 
there can be even longer delays.

I'm not suggesting you're incorrect or wrong in anything you say, but 
it's important for anyone new to the parts to keep in mind all of the 
above before implementing a particular solution. If you're happy that 
after doing the analysis that the timing is OK, then fine. However, 
don't skip the analysis, particularly if you're planning to respond 
to "fast" events. 

One thing you find is that it is very hard to guarantee to respond at 
a very precise time after any interrupt: there is usually quite a bit 
of jitter involved. In most cases, such as flipping the direction of 
a capture i/p "somewhere" in an ISR this won't matter, but in others 
it will.

Brendan

P.S. there's been plenty of posts to the forum on exact timings of 
peripheral bus access and interrupt latencies: this is just a 
reminder that they exist, rather than a repeat of the actual data 
involved.

--- In lpc2000@lpc2..., Onestone <onestone@...> wrote:
>
> The 'standard' way to do this is to use 1 pin. ISR latency on slow 
small 
> micros is usually more than fast enough. On an LPC it should be a 
shoe 
> in. 1 instruction cycle to flip the bit sense. How hard can it be. 
A 
> typical ISR to measure pulse width on most micros requires fewer 
than 10 
> instructions. Your final sentence may be true, but this is the case 
in 
> 99% of applications, and is certainly true in your case, even with 
the 
> comparatively poor interrupt latency of the LPC2xxx. On the odd 
> occasions where the pulses are too fast I would suggest that using 
two 
> pins is a poor solution anyway, since the resolution of meaurement 
will 
> only be typically 2-4 bits at most, and other solutions would offer 
a 
> better result.
> 
> Cheers
> 
> Al
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi brendan,  I am aware of the latencies with the LPC, especially the 
over discussed slow I/O issues. I am also aware of the odd interrupt 
latency issues (for a supposed RISC machine), but promoting them touse 
the FIQ ISR helps resolve some of these issues. Knowing the exact isr 
latency isn't really an issue in timer capture for pulse timing, as long 
as the ISR is taken and completed before the next edge to be detected, 
since the time of the event is stored, like time travel backwards, and, 
since the post I responded to discussed 1ms/20ms remote control signals 
ISR latency and single pin handling certainly wasn't going to be an 
issue. I do appreciate that the LPC is not really a conventional 
microcontroller, more like a microprocessor with the extra hardware 
kludged into the same silicon.

Thansk for the reminders though

Al
	brendanmurphy37 wrote:

>Al,
>
>You're right in most circumstances. However, anyone reading this 
>needs to be aware that the LPC2xxx parts, like many other 32-bit 
>micros with pipelined architectures and multiple (internal) buses, 
>are not quite as straightforward as previous generation micros. For 
>example, the "1 instruction cycle to flip the bit sense" you refer to 
>will actually take multiple clocks, due to the latency of the 
>peripheral bus.
>
>Interrupt latency is also not straightforward to work out, as it will 
>include some or all of:
>
>- delay to due to background software disabling interrupts
>- variable instruction execution delay (ARM is not very "RISC" like 
>in this respect, due to extended instructions such as load multiple)
>- variable hardware interrupt acknowledgement delay
>- software delay in saving additional context and calling correct ISR
>
>If your interrupt software isn't set up to handle nested interrupts, 
>there can be even longer delays.
>
>I'm not suggesting you're incorrect or wrong in anything you say, but 
>it's important for anyone new to the parts to keep in mind all of the 
>above before implementing a particular solution. If you're happy that 
>after doing the analysis that the timing is OK, then fine. However, 
>don't skip the analysis, particularly if you're planning to respond 
>to "fast" events. 
>
>One thing you find is that it is very hard to guarantee to respond at 
>a very precise time after any interrupt: there is usually quite a bit 
>of jitter involved. In most cases, such as flipping the direction of 
>a capture i/p "somewhere" in an ISR this won't matter, but in others 
>it will.
>
>Brendan
>
>P.S. there's been plenty of posts to the forum on exact timings of 
>peripheral bus access and interrupt latencies: this is just a 
>reminder that they exist, rather than a repeat of the actual data 
>involved.
>
>--- In lpc2000@lpc2..., Onestone <onestone@...> wrote:
>  
>
>>The 'standard' way to do this is to use 1 pin. ISR latency on slow 
>>    
>>
>small 
>  
>
>>micros is usually more than fast enough. On an LPC it should be a 
>>    
>>
>shoe 
>  
>
>>in. 1 instruction cycle to flip the bit sense. How hard can it be. 
>>    
>>
>A 
>  
>
>>typical ISR to measure pulse width on most micros requires fewer 
>>    
>>
>than 10 
>  
>
>>instructions. Your final sentence may be true, but this is the case 
>>    
>>
>in 
>  
>
>>99% of applications, and is certainly true in your case, even with 
>>    
>>
>the 
>  
>
>>comparatively poor interrupt latency of the LPC2xxx. On the odd 
>>occasions where the pulses are too fast I would suggest that using 
>>    
>>
>two 
>  
>
>>pins is a poor solution anyway, since the resolution of meaurement 
>>    
>>
>will 
>  
>
>>only be typically 2-4 bits at most, and other solutions would offer 
>>    
>>
>a 
>  
>
>>better result.
>>
>>Cheers
>>
>>Al
>>
>>    
>>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Al,

Why would the capture resolution using two capture pins only be 2-4
bits at most?

One note on using an ISR for flipping the capture edge, this works
fine if the signal you're capturing is not noisy..  Determinism in
hard-realtime systems goes away anytime interrupts can be triggered by
external noise.

-Ryan
	--- In lpc2000@lpc2..., Onestone <onestone@...> wrote:
>
> The 'standard' way to do this is to use 1 pin. ISR latency on slow
small 
> micros is usually more than fast enough. On an LPC it should be a shoe 
> in. 1 instruction cycle to flip the bit sense. How hard can it be. A 
> typical ISR to measure pulse width on most micros requires fewer
than 10 
> instructions. Your final sentence may be true, but this is the case in 
> 99% of applications, and is certainly true in your case, even with the 
> comparatively poor interrupt latency of the LPC2xxx. On the odd 
> occasions where the pulses are too fast I would suggest that using two 
> pins is a poor solution anyway, since the resolution of meaurement will 
> only be typically 2-4 bits at most, and other solutions would offer a 
> better result.
> 
> Cheers
> 
> Al
> 
> Ryan Niemi wrote:
> 
> >I recently implemented pulse width measurement on an LPC2124 to detect
> >the width of pulses from an R/C radio receiver (varies between 1ms and
> >2ms positive-going pulse width) for a theatrical motion control and
> >lighting control project.  There's an interesting shortcoming that I
> >encountered, each capture pin can only capture a rising or falling
> >edge, but not both.  So to measure pulse width, I found it necessary
> >to use *two* capture pins tied together, one to capture the rising
> >edge and another to capture the falling edge.  The main loop of the
> >program compares the two, and if the count on the falling edge capture
> >is larger than the count on the rising edge capture, then pulse_width
> >= falling_edge_capture - rising_edge_capture.
> >
> >The Hitex book includes an example whose description says it measures
> >a pulse width, but the example shown (using one capture pin) very
> >clearly does not measure pulse width and is incomplete, and merely
> >measures the time between pulses (but not the pulse width).  Now my
> >curiosity is had, has anyone succeeded in measuring pulse widths
> >without using multiple capture pins?  From the way the LPC capture
> >units are set up, I doubt it's possible, short of flipping the capture
> >edge polarity in an ISR.  ISR-based solutions are only really useful
> >if the pulse width is larger than the execution time of the ISR + any
> >interrupt latency due to other ISR's executing at the time.
> >
> >-Ryan
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

If the signal is too fast to be captured by a single capture pin, using 
the edge flipping method, then it is occuring faster than the capture 
ISR can execute, and reservice itself.  Assuming that the ISR is well 
written, executes in the absolute minimum possible time, ie no calls , 
no massive processing in the ISR, then the pulse  is obviously very 
short. having one edge captured by pinA and the other by pin B won't 
change this, in fact the nett time to execute and service the two 
routines will be shorter, typically, than the nett  time to service a 
single bit flipping routine, and the pulse, depending upon the processor 
of course, will typically be only a few counts long,  thus a few bits of 
resolution, and a limited dynamic range. In this case other methods 
would perform the task better.

With respect to noise in the system, this is where I believe system 
design enters the picture. In this case if the time is taken to learn 
the system before ever laying down hardware or software, and the 
vagaries of the signals are studied and understood first, not discovered 
to be a problem later, as seems to be the more common event, then they 
can be first of all minimised during the hardware design, then perhaps 
compensated for during the software design with signal or logical 
filters, or a combination.

Cheers

Al

Ryan Niemi wrote:

>Hi Al,
>
>Why would the capture resolution using two capture pins only be 2-4
>bits at most?
>
>One note on using an ISR for flipping the capture edge, this works
>fine if the signal you're capturing is not noisy..  Determinism in
>hard-realtime systems goes away anytime interrupts can be triggered by
>external noise.
>
>-Ryan
>
>
>--- In lpc2000@lpc2..., Onestone <onestone@...> wrote:
>  
>
>>The 'standard' way to do this is to use 1 pin. ISR latency on slow
>>    
>>
>small 
>  
>
>>micros is usually more than fast enough. On an LPC it should be a shoe 
>>in. 1 instruction cycle to flip the bit sense. How hard can it be. A 
>>typical ISR to measure pulse width on most micros requires fewer
>>    
>>
>than 10 
>  
>
>>instructions. Your final sentence may be true, but this is the case in 
>>99% of applications, and is certainly true in your case, even with the 
>>comparatively poor interrupt latency of the LPC2xxx. On the odd 
>>occasions where the pulses are too fast I would suggest that using two 
>>pins is a poor solution anyway, since the resolution of meaurement will 
>>only be typically 2-4 bits at most, and other solutions would offer a 
>>better result.
>>
>>Cheers
>>
>>Al
>>
>>Ryan Niemi wrote:
>>
>>    
>>
>>>I recently implemented pulse width measurement on an LPC2124 to detect
>>>the width of pulses from an R/C radio receiver (varies between 1ms and
>>>2ms positive-going pulse width) for a theatrical motion control and
>>>lighting control project.  There's an interesting shortcoming that I
>>>encountered, each capture pin can only capture a rising or falling
>>>edge, but not both.  So to measure pulse width, I found it necessary
>>>to use *two* capture pins tied together, one to capture the rising
>>>edge and another to capture the falling edge.  The main loop of the
>>>program compares the two, and if the count on the falling edge capture
>>>is larger than the count on the rising edge capture, then pulse_width
>>>= falling_edge_capture - rising_edge_capture.
>>>
>>>The Hitex book includes an example whose description says it measures
>>>a pulse width, but the example shown (using one capture pin) very
>>>clearly does not measure pulse width and is incomplete, and merely
>>>measures the time between pulses (but not the pulse width).  Now my
>>>curiosity is had, has anyone succeeded in measuring pulse widths
>>>without using multiple capture pins?  From the way the LPC capture
>>>units are set up, I doubt it's possible, short of flipping the capture
>>>edge polarity in an ISR.  ISR-based solutions are only really useful
>>>if the pulse width is larger than the execution time of the ISR + any
>>>interrupt latency due to other ISR's executing at the time.
>>>
>>>-Ryan
>>>      
>>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I am a little confused about CRP.
I am working with LPC2106. That chip have or havent CRP? I read somewhere that 
CRP is on LPC2106 after some version, thats true or LPC2106 do not have CRP 
at all?
Is there a way to protect my firmware agains piracy or my firmware will 
allways be open to anyone read it?

Thanx a lot for any reply!

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi all,

We're currently in the process of putting together a device that will be
powered via an induction ring and as such there is the potential for the
device to lose sufficient power intermittantly.

I was wondering on peoples' general opinion of using an external supervisor
chip to ensure a clean startup by keeping reset pulled to ground for a
period of around 150 milliseconds.
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Wow, very tough working condition for that Arm Chip...    
and interesting...  :)

May be you should use both power supervisor/monitor chip + external
Hardware WDT. => WDT "kicks" the CPU again if it does not power up
properly.

I've seen some AVR chips flash program-able for WDT always on after
reset.  (WDT default as on after reset)

Could you help eMail me your experience after the project??
Thanks in advance!
Regards
	--- In lpc2000@lpc2..., "Andrew Berney" <amb@...> wrote:
>
> Hi all,
> 
> We're currently in the process of putting together a device that 
will be
> powered via an induction ring and as such there is the potential 
for the
> device to lose sufficient power intermittantly.
> 
> I was wondering on peoples' general opinion of using an external 
supervisor
> chip to ensure a clean startup by keeping reset pulled to ground 
for a
> period of around 150 milliseconds.
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Sorry, All LPC2xxx chips have flash memory locking except
 LPC2104/LPC2105/LPC2106...  :)
So far, I think there is only one silicon ver for LPC2104/5/6.
Have not heard of any new silicon yet!
Regards

--- In lpc2000@lpc2..., Xtian Xultz <xultz@...> wrote:
>
> I am a little confused about CRP.
> I am working with LPC2106. That chip have or havent CRP? I read 
somewhere that 
> CRP is on LPC2106 after some version, thats true or LPC2106 do not 
have CRP 
> at all?
> Is there a way to protect my firmware agains piracy or my firmware 
will 
> allways be open to anyone read it?
> 
> Thanx a lot for any reply!
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Quoting Xtian Xultz <xultz@xult...>:
> I am a little confused about CRP.
> I am working with LPC2106. That chip have or havent CRP? I read
> somewhere that
> CRP is on LPC2106 after some version, thats true or LPC2106 do not have CRP
> at all?

LPC 2104/5/6 do not have CRP

> Is there a way to protect my firmware agains piracy or my firmware will
> allways be open to anyone read it?

Presumably they also would have to copy your hardware.

Robert
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Xtian,

unfortunately the LPC2104/5/6 do not have a protection against reading 
your code through a debug channel.

We are however working on such a version that will include CRP and it 
is scheduled to be available to the market in Q3 of this year. 

Robert

--- In lpc2000@lpc2..., Xtian Xultz <xultz@...> wrote:
>
> I am a little confused about CRP.
> I am working with LPC2106. That chip have or havent CRP? I read 
somewhere that 
> CRP is on LPC2106 after some version, thats true or LPC2106 do not 
have CRP 
> at all?
> Is there a way to protect my firmware agains piracy or my firmware 
will 
> allways be open to anyone read it?
> 
> Thanx a lot for any reply!
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I had startup issues when the power supply did not ramp up the voltage
fast enough. The reset supervisor will make sure you reached the
operating voltage and then apply the delay. If your CPU is locked up
in a slow startup of the core voltage when peripheral supply already
applied the watchdog might not work. Is there a specification for
these conditions?

--- In lpc2000@lpc2..., "unity0724" <unity0724@...> wrote:
>
> Wow, very tough working condition for that Arm Chip...    
> and interesting...  :)
> 
> May be you should use both power supervisor/monitor chip + external
> Hardware WDT. => WDT "kicks" the CPU again if it does not power up
> properly.
> 
> I've seen some AVR chips flash program-able for WDT always on after
> reset.  (WDT default as on after reset)
> 
> Could you help eMail me your experience after the project??
> Thanks in advance!
> Regards
> 
> 
> --- In lpc2000@lpc2..., "Andrew Berney" <amb@> wrote:
> >
> > Hi all,
> > 
> > We're currently in the process of putting together a device that 
> will be
> > powered via an induction ring and as such there is the potential 
> for the
> > device to lose sufficient power intermittantly.
> > 
> > I was wondering on peoples' general opinion of using an external 
> supervisor
> > chip to ensure a clean startup by keeping reset pulled to ground 
> for a
> > period of around 150 milliseconds.
> >
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Sorry, could not fully understand your question. 
I was suggesting extra external hardware WDT to Mr Andrew Berney as
there might be cases of CPU not starting up, even with H/W 
reset/power supervisor.  His type of working condition is just too
tough for the CPU.

If external hardware WDT is installed, this type of hardware WDT are
normally cleared by reset (Power supply below threshold level) and
will start to "WDT ticking" only after the reset (Power is above
threshold level + some reset delay).   It will always ensure some
fixed WDT timeout after reset before that WDT "bites" (typically 1-2
seconds).

For the core voltage delay, it is the duty of the reset/power
supervisor chip to have enough extra reset delay, typical 50-200mS 
(extra reset delay after 3.3V power good to be longer than your 1.8V
LDO ramp delay)

Regards

--- In lpc2000@lpc2..., "lpcarmed" <lpcarmed@...> wrote:
>
> I had startup issues when the power supply did not ramp up the 
voltage
> fast enough. The reset supervisor will make sure you reached the
> operating voltage and then apply the delay. If your CPU is locked 
up
> in a slow startup of the core voltage when peripheral supply 
already
> applied the watchdog might not work. Is there a specification for
> these conditions?
> 
> --- In lpc2000@lpc2..., "unity0724" <unity0724@> wrote:
> >
> > Wow, very tough working condition for that Arm Chip...    
> > and interesting...  :)
> > 
> > May be you should use both power supervisor/monitor chip + 
external
> > Hardware WDT. => WDT "kicks" the CPU again if it does not power 
up
> > properly.
> > 
> > I've seen some AVR chips flash program-able for WDT always on 
after
> > reset.  (WDT default as on after reset)
> > 
> > Could you help eMail me your experience after the project??
> > Thanks in advance!
> > Regards
> > 
> > 
> > --- In lpc2000@lpc2..., "Andrew Berney" <amb@> wrote:
> > >
> > > Hi all,
> > > 
> > > We're currently in the process of putting together a device 
that 
> > will be
> > > powered via an induction ring and as such there is the 
potential 
> > for the
> > > device to lose sufficient power intermittantly.
> > > 
> > > I was wondering on peoples' general opinion of using an 
external 
> > supervisor
> > > chip to ensure a clean startup by keeping reset pulled to 
ground 
> > for a
> > > period of around 150 milliseconds.
> > >
> >
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Cheers for the input guys.

The actual environment this board will live in is on a steel propeller shaft
rotating at up to 1000Rpm (not an ideal environment but given its job is to
measure physical parameters of the shaft somewhat unavoidable). Due to the
nature of the rotation and required freedom, power is provided by induction
from a power head mounted close to the shaft, however this can lead to
intermittent problems with power loss/surge. Surge and spikes we can deal
with electronically however power drop/loss can lead to the ramp condition
you both describe. Hence I'm looking at the potential use of an external
supervisor / WDT and wondered if anyone had had any prior experience using
them with the Philips Micros.
	-----Original Message-----
From: lpc2000@lpc2... [mailto:lpc2000@lpc2...]On Behalf
Of unity0724
Sent: 11 March 2006 01:53
To: lpc2000@lpc2...
Subject: [lpc2000] Re: Use of external reset supervisor chips
	Sorry, could not fully understand your question.
I was suggesting extra external hardware WDT to Mr Andrew Berney as
there might be cases of CPU not starting up, even with H/W
reset/power supervisor.  His type of working condition is just too
tough for the CPU.

If external hardware WDT is installed, this type of hardware WDT are
normally cleared by reset (Power supply below threshold level) and
will start to "WDT ticking" only after the reset (Power is above
threshold level + some reset delay).   It will always ensure some
fixed WDT timeout after reset before that WDT "bites" (typically 1-2
seconds).

For the core voltage delay, it is the duty of the reset/power
supervisor chip to have enough extra reset delay, typical 50-200mS
(extra reset delay after 3.3V power good to be longer than your 1.8V
LDO ramp delay)

Regards

--- In lpc2000@lpc2..., "lpcarmed" <lpcarmed@...> wrote:
>
> I had startup issues when the power supply did not ramp up the
voltage
> fast enough. The reset supervisor will make sure you reached the
> operating voltage and then apply the delay. If your CPU is locked
up
> in a slow startup of the core voltage when peripheral supply
already
> applied the watchdog might not work. Is there a specification for
> these conditions?
>
> --- In lpc2000@lpc2..., "unity0724" <unity0724@> wrote:
> >
> > Wow, very tough working condition for that Arm Chip...
> > and interesting...  :)
> >
> > May be you should use both power supervisor/monitor chip +
external
> > Hardware WDT. => WDT "kicks" the CPU again if it does not power
up
> > properly.
> >
> > I've seen some AVR chips flash program-able for WDT always on
after
> > reset.  (WDT default as on after reset)
> >
> > Could you help eMail me your experience after the project??
> > Thanks in advance!
> > Regards
> >
> >
> > --- In lpc2000@lpc2..., "Andrew Berney" <amb@> wrote:
> > >
> > > Hi all,
> > >
> > > We're currently in the process of putting together a device
that
> > will be
> > > powered via an induction ring and as such there is the
potential
> > for the
> > > device to lose sufficient power intermittantly.
> > >
> > > I was wondering on peoples' general opinion of using an
external
> > supervisor
> > > chip to ensure a clean startup by keeping reset pulled to
ground
> > for a
> > > period of around 150 milliseconds.
> > >
> >
>
	Yahoo! Groups Links
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I've got experience with the LPC2132 not handling a brown-out 
condtion.  In my case, when the Vcc dropped to around 1V, and then 
back up to 3.3V, the CPU locked up, and would not recover.  External 
reset will not clear this condition.  The only way I found to do it 
was remove Vcc, then let it come back on.  If you have a system 
where DC power will routinely ramp down and up, and may not go all 
the way to 0V when it goes off, I highly suggest using something to 
monitor the INPUT to the voltage regulator, and turn the regulator 
off when its input is low.  The external WDT is probably a good idea 
also. 
John
--- In lpc2000@lpc2..., "Andrew Berney" <amb@...> wrote:
>
> Cheers for the input guys.
> 
> The actual environment this board will live in is on a steel 
propeller shaft
> rotating at up to 1000Rpm (not an ideal environment but given its 
job is to
> measure physical parameters of the shaft somewhat unavoidable). 
Due to the
> nature of the rotation and required freedom, power is provided by 
induction
> from a power head mounted close to the shaft, however this can 
lead to
> intermittent problems with power loss/surge. Surge and spikes we 
can deal
> with electronically however power drop/loss can lead to the ramp 
condition
> you both describe. Hence I'm looking at the potential use of an 
external
> supervisor / WDT and wondered if anyone had had any prior 
experience using
> them with the Philips Micros.
> 
> 
> 
> -----Original Message-----
> From: lpc2000@lpc2... [mailto:lpc2000@lpc2...]On 
Behalf
> Of unity0724
> Sent: 11 March 2006 01:53
> To: lpc2000@lpc2...
> Subject: [lpc2000] Re: Use of external reset supervisor chips
> 
> 
> Sorry, could not fully understand your question.
> I was suggesting extra external hardware WDT to Mr Andrew Berney as
> there might be cases of CPU not starting up, even with H/W
> reset/power supervisor.  His type of working condition is just too
> tough for the CPU.
> 
> If external hardware WDT is installed, this type of hardware WDT 
are
> normally cleared by reset (Power supply below threshold level) and
> will start to "WDT ticking" only after the reset (Power is above
> threshold level + some reset delay).   It will always ensure some
> fixed WDT timeout after reset before that WDT "bites" (typically 1-
2
> seconds).
> 
> For the core voltage delay, it is the duty of the reset/power
> supervisor chip to have enough extra reset delay, typical 50-200mS
> (extra reset delay after 3.3V power good to be longer than your 
1.8V
> LDO ramp delay)
> 
> Regards
> 
> --- In lpc2000@lpc2..., "lpcarmed" <lpcarmed@> wrote:
> >
> > I had startup issues when the power supply did not ramp up the
> voltage
> > fast enough. The reset supervisor will make sure you reached the
> > operating voltage and then apply the delay. If your CPU is locked
> up
> > in a slow startup of the core voltage when peripheral supply
> already
> > applied the watchdog might not work. Is there a specification for
> > these conditions?
> >
> > --- In lpc2000@lpc2..., "unity0724" <unity0724@> wrote:
> > >
> > > Wow, very tough working condition for that Arm Chip...
> > > and interesting...  :)
> > >
> > > May be you should use both power supervisor/monitor chip +
> external
> > > Hardware WDT. => WDT "kicks" the CPU again if it does not
power
> up
> > > properly.
> > >
> > > I've seen some AVR chips flash program-able for WDT always on
> after
> > > reset.  (WDT default as on after reset)
> > >
> > > Could you help eMail me your experience after the project??
> > > Thanks in advance!
> > > Regards
> > >
> > >
> > > --- In lpc2000@lpc2..., "Andrew Berney" <amb@> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > We're currently in the process of putting together a device
> that
> > > will be
> > > > powered via an induction ring and as such there is the
> potential
> > > for the
> > > > device to lose sufficient power intermittantly.
> > > >
> > > > I was wondering on peoples' general opinion of using an
> external
> > > supervisor
> > > > chip to ensure a clean startup by keeping reset pulled to
> ground
> > > for a
> > > > period of around 150 milliseconds.
> > > >
> > >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )