Reply by Tom Walsh October 19, 20052005-10-19
Landrum Haddix wrote:

>Update:
>
>The other day I reported it seemed my LPC2138 was hanging with the
>clock stopped and the internal watchdog not working.
>
>Turns out the processor was running so the watchdog was being stroked
>hence not firing.
>
>What was happening were I/O lines were changing state after an ESD hit.
>In my case this turned off most of my board making it look dead.
>
>Only some I/O lines were flipping, so it's not an easy state to detect.
>
>I've seen this before, I guess it means I need to keep internal copies
>of the ports and periodically refresh them. Of course this will only
>work for logic that can handle a pin toggling as long as it returns to
>the correct state. Something edge triggered would hate this.
>
>Anyhow we solved the ESD problem by metallizing the plastic lid
>enclosing the board. >
I was going to offer the Faraday Shield as a solution.... heh

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


An Engineer's Guide to the LPC2100 Series

Reply by Landrum Haddix October 19, 20052005-10-19
Update:

The other day I reported it seemed my LPC2138 was hanging with the
clock stopped and the internal watchdog not working.

Turns out the processor was running so the watchdog was being stroked
hence not firing.

What was happening were I/O lines were changing state after an ESD hit.
In my case this turned off most of my board making it look dead.

Only some I/O lines were flipping, so it's not an easy state to detect.

I've seen this before, I guess it means I need to keep internal copies
of the ports and periodically refresh them. Of course this will only
work for logic that can handle a pin toggling as long as it returns to
the correct state. Something edge triggered would hate this.

Anyhow we solved the ESD problem by metallizing the plastic lid
enclosing the board.

We took 180 consecturive hits at 25kv without crash or reboot.

Pardon my alarm.

Landrum Haddix
lhaddix@lhad...
http://web.qx.net/lhaddix


Reply by Robert Adsett October 18, 20052005-10-18
At 10:12 PM 10/17/05 -0400, Landrum Haddix wrote:
> > I think the additional micro as watchdog is not a bad idea. A little 8
> pin
> > micro can act as quit a flexible watchdog. 1 pin for reset, 1 as the
> > watchdog input, a couple to check for various startup or runtime
> > conditions. If it has a good reliable power monitor built in even
> > better. It' may even be cost competitive with a windowed watchdog.
> >
> > Jack Ganselle has an article where he waxes rhapsodic about the
> possibilities.
> >
> > Robert
>
>Robert,
>We thought of that today. There are some SOT-23 PICs with 4 I/O that
>would be cheap and perfect. Downside is they have to be programmed
>somehow. So far my design is entirely flashable from outside.

Well there is something to be said for having your watchdog be
non-modifiable :)

>You could even speak I2C to it and schedule the next reset pulse to
>occur if there is no further comm. This could even include as special
>value for the duration that meant disable the watchdog function.
>
>It's dissapointing however to have to use a PIC beacuse it has a
>reliable watchdog and BOR to pull reset on the ARM because it doesn't.

Well, I've always been too paranoid to rely on a micro to provide a reset
output in the case of brownout. A fair power monitor circuit has to
guarantee a low out (not floating) down to a Vcc of 0.8V, a good one should
go lower. Especially important as supply voltages drift ever lower.

One of these days I'll sit down and satisfy myself that it can be made to
work. The non power side I'm convinced of.

Which raises a question for the original poster. Do you have a power
monitor that provides a reset when your power line goes low. Pulses on the
power line could give you the symptoms you see. And given the environment
you describe a ground bounce is not out of the question.

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/


Reply by Tom Walsh October 18, 20052005-10-18
Landrum Haddix wrote:

>TomW,
>We use a gun and step from a couple of KV to +/-25KV.
>All of my connector pins pass though these surge devices
>we use called SurgX that will clamp the pulse to 30v and turn
>on in about 50ps. My connectors can handle being hit directly. >
This almost sounds like a High-Energy Laser controller... >However our board is mounted in a metal frame which they
>also shoot with the gun. At first we had the board isolated from
>the frame, but the only way out for the pulse is the ground plane
>on the board so it flashes over to the board. (As much as 3/4"!!!)
>
>I stopped this by giving the board a low impedance ground to the
>frame so the whole thing bounces up and down as quickly as possible.
>This prevents component damage, but still apparently leaves gradients
>that will freak out the ARM. >
Well, all I can say is that I am glad it is you and not me with this
problem. In the field that I do stuff, if we had that much voltage
dancing around the metal enclosure, it won't matter what the outcome
would be... heh We only have to deal with the vulnerability of the
external connections. TomW --
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------


Reply by Landrum Haddix October 17, 20052005-10-17
> I think the additional micro as watchdog is not a bad idea. A little 8 pin
> micro can act as quit a flexible watchdog. 1 pin for reset, 1 as the
> watchdog input, a couple to check for various startup or runtime
> conditions. If it has a good reliable power monitor built in even
> better. It' may even be cost competitive with a windowed watchdog.
>
> Jack Ganselle has an article where he waxes rhapsodic about the possibilities.
>
> Robert

Robert,
We thought of that today. There are some SOT-23 PICs with 4 I/O that
would be cheap and perfect. Downside is they have to be programmed
somehow. So far my design is entirely flashable from outside.

You could even speak I2C to it and schedule the next reset pulse to
occur if there is no further comm. This could even include as special
value for the duration that meant disable the watchdog function.

It's dissapointing however to have to use a PIC beacuse it has a
reliable watchdog and BOR to pull reset on the ARM because it doesn't.

Landrum Haddix
lhaddix@lhad...
http://web.qx.net/lhaddix


Reply by Landrum Haddix October 17, 20052005-10-17
TomW,
We use a gun and step from a couple of KV to +/-25KV.
All of my connector pins pass though these surge devices
we use called SurgX that will clamp the pulse to 30v and turn
on in about 50ps. My connectors can handle being hit directly.

However our board is mounted in a metal frame which they
also shoot with the gun. At first we had the board isolated from
the frame, but the only way out for the pulse is the ground plane
on the board so it flashes over to the board. (As much as 3/4"!!!)

I stopped this by giving the board a low impedance ground to the
frame so the whole thing bounces up and down as quickly as possible.
This prevents component damage, but still apparently leaves gradients
that will freak out the ARM.

We have a four layer board with both outside layers as ground planes.
As well as inner ground polygons poured around the traces.
A ton of vias stitch the grounds planes together as well.

However I'm still thinking we can get a pretty good gradient between
some of the nets when the board takes a hit. (25kv human body model
is a lot of bang...)

I also run many of the lines after passing through the surgx devices
through BAV99 diode clamps to both rails.

About all I can do is ground all 4 edges of the board rather than just
the single 1/2" copper tape tail the board has soldered to it now.

As I said we can take 25Kv no sweat it just sometimes crashes the
micro.

With a reliable watchdog it would come right back up. Landrum Haddix
lhaddix@lhad...
http://web.qx.net/lhaddix


Reply by Peter Jakacki October 17, 20052005-10-17
I've been using an external 8-pin micro as a reset/watchdog control for
years. Originally I used the PIC12C509 and more recently the 12C629 as
they have proved very reliable. Even the LPC903, albeit in SMD. Use the
internal RC oscillator, apply VDD and presto. The watchdog can be a
smart watchdog that requires a serial bit stream to start it up and
continue to activate it or whatever you like.

But I never waste resources as this micro always monitors my main coms
receive line and allows me to remotely reset, stop, or place the host
micro in bootload mode. Back in the nineties I was guilty of using AVRs
which did not have any internal boot code but could be Flash programmed
via an SPI like interface. So the external reset micro would be kind
enough to receive an intel hex file and burn it in line by line, all
over a 3-wire serial interface. Of course, I use them on my LPC2000s as
well.

One reason I like the 8-pin DIP format is for that reason ... DIP, as
everything else tends to be smd I can still burn my special watchdog
chip externally and then plug it in. I even code serial numbers in these
little suckers. I have yet to make one of these lock-up or even glitch.

There you go, combo reset/watchdog/ISP/serial# chip, all for a buck.

..and yes, I have waxed lyrical about this once or twice before.

my2cents
*Peter*

Robert Adsett wrote:

>At 12:04 AM 10/18/05 +0200, Sten wrote: >>lhaddix wrote:
>>
>>
>>>I guess as Marcio points out the larger issue is why are there
>>>situations where the internal watchdog can't reset the micro.
>>>Unfortunately this is probably a feature of the LPC design.
>>>
>>>Microchip uses an internal RC for thier watchdog which is not
>>>dependant of the system clock for instance.
>>>
>>>I think what happens is it's possible for an ESD hit to stop
>>>the crystal osc on the LPC such that reset is needed to restart
>>>the oscillator, but there can be no watchdog reset without a system
>>>clock.
>>>
>>>I've considered using an external osc to feed the ARM, but don't
>>>wish to do this. I can't be sure it would fix the problem without
>>>mocking it up and then blasting with the static gun, but I know that
>>>toggling reset from outside will restart the clock.
>>>
>>>Landrum
>>>
>>>
>>>
>>I had some similar problems with a LPC2124 last year. During ESD test
>>the LPC stops with and without internal watchdog. But we had another
>>(bigger) MCU on our board which was able to turn off/turn on the LPC if
>>it didn't response to hello-request packet in such a case.
>>
> >I think the additional micro as watchdog is not a bad idea. A little 8 pin
>micro can act as quit a flexible watchdog. 1 pin for reset, 1 as the
>watchdog input, a couple to check for various startup or runtime
>conditions. If it has a good reliable power monitor built in even
>better. It' may even be cost competitive with a windowed watchdog.
>
>Jack Ganselle has an article where he waxes rhapsodic about the possibilities.
>
>Robert




Reply by Robert Adsett October 17, 20052005-10-17
At 12:04 AM 10/18/05 +0200, Sten wrote:
>lhaddix wrote:
> > I guess as Marcio points out the larger issue is why are there
> > situations where the internal watchdog can't reset the micro.
> > Unfortunately this is probably a feature of the LPC design.
> >
> > Microchip uses an internal RC for thier watchdog which is not
> > dependant of the system clock for instance.
> >
> > I think what happens is it's possible for an ESD hit to stop
> > the crystal osc on the LPC such that reset is needed to restart
> > the oscillator, but there can be no watchdog reset without a system
> > clock.
> >
> > I've considered using an external osc to feed the ARM, but don't
> > wish to do this. I can't be sure it would fix the problem without
> > mocking it up and then blasting with the static gun, but I know that
> > toggling reset from outside will restart the clock.
> >
> > Landrum
> >
>
>I had some similar problems with a LPC2124 last year. During ESD test
>the LPC stops with and without internal watchdog. But we had another
>(bigger) MCU on our board which was able to turn off/turn on the LPC if
>it didn't response to hello-request packet in such a case.


I think the additional micro as watchdog is not a bad idea. A little 8 pin
micro can act as quit a flexible watchdog. 1 pin for reset, 1 as the
watchdog input, a couple to check for various startup or runtime
conditions. If it has a good reliable power monitor built in even
better. It' may even be cost competitive with a windowed watchdog.

Jack Ganselle has an article where he waxes rhapsodic about the possibilities.

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/


Reply by Tom Walsh October 17, 20052005-10-17
lhaddix wrote:

>Hi,
>I'm working on an LPC2138 design and just moved
>into ESD testing. After some ESD hits there was
>no damage, but the processor would be left not
>running. >
I'm wondering why you would subject a board's electronics to a static
discharge?? When we go through U/L testings, they zap us with an ESD on
the inputs of the board, but they don't start showering the board with
static charges.

In our case, it is a matter of going after the source of the problem,
the EMF wave introduced by the discharge. I had one design where it
used an AT style keyboard. Sometimes when you plugged the keyboard in,
the 8041 processor would lockup, in that case also, you had to power
cycle the processor to get it working again. Our solution had been
simple, add a couple of silicon (1N4148) diodes to the signal lines in
question to dump the excess voltage into the power supply bus (low
impedance).

Other solutions we use is the classic Transorb (gas tube), resistor and
Transil (high speed zenor). This works exceptionally well in situations
where high-voltage may be induced into wiring due to nearby lightning
storms.

IMHO, you are working towards the solution backwards? I mean, fixing
the result rather than the cause?

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


Reply by Sten October 17, 20052005-10-17
lhaddix wrote:
> Sten,
> What do you mean 'bad foul!!!' my design or this situation?
The situation of course! This is like building a house without a door. ;-)

>
> I think I will add circuitry to inhibit the external watchdog
> when P0.14 is low. I also want to inhibit the external watchdog
> when my 20pin JTAG is in use.
>
> What can I sense to tell if the JTAG port is connected to an
> emulator?

Roberts idea with the JTAG-Enable pin (RTCK) is quite good. If you
pull-up this pin (e.g. LPC2138) JTAG is enabled. If this pin is
unconnected (or pulled-low) JTAG will be disabled.

>
> I thought about counting on one of it's many grounds
> pulling a pin low, but would rather use something that didn't
> depend on certain grounds being connected inside the emulator
> pod.
Mmmmh...

>
> I guess as Marcio points out the larger issue is why are there
> situations where the internal watchdog can't reset the micro.
> Unfortunately this is probably a feature of the LPC design.
>
> Microchip uses an internal RC for thier watchdog which is not
> dependant of the system clock for instance.
>
> I think what happens is it's possible for an ESD hit to stop
> the crystal osc on the LPC such that reset is needed to restart
> the oscillator, but there can be no watchdog reset without a system
> clock.
>
> I've considered using an external osc to feed the ARM, but don't
> wish to do this. I can't be sure it would fix the problem without
> mocking it up and then blasting with the static gun, but I know that
> toggling reset from outside will restart the clock.
>
> Landrum
>

I had some similar problems with a LPC2124 last year. During ESD test
the LPC stops with and without internal watchdog. But we had another
(bigger) MCU on our board which was able to turn off/turn on the LPC if
it didn't response to hello-request packet in such a case.

Sten
--
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?

http://nanortos.net-attack.de/

Or some open-source tools and code for LPC2000?

http://www.net-attack.de/

************************************************/