CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Random reset of PIC - application
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

Random reset of PIC - application
PostPosted: Mon Jan 14, 2008 4:45 am     Reply with quote

Hi,

I have a problem with our application. The device sometimes resets of its own. Not very often though, as a matter of fact, I haven't really been able to simulate the problem, but some people are complaining about it.

Now is the time to make another revision of the hardware pcb's and I want to solve this problem. I want to make sure that no random reset can occur.

The application is built around a PIC16LF877A. It operates at 3V. The device consists out of 3 PCB's:



1. carrier board: power circuitry, some I/O, PIC reset button connected to MCLR.
2. Keyboard: PIC processor (on bottom), keyboard matrix.
3. cursorrouting: a series of switches that are connected to the PIC in a matrix.

The keyboard is connected to the carrierboard via 1 board to board connector. The cursorrouting is connected to the keyboard via 2 board 2 board connectors.

Personnally, I see the reset problem can have several problems:

1. ESD causes device to reset
I think this is the main cause that makes the device reset. The metal housing of the switches on the cursorrouting attractes an ESD spark, and this makes the PIC reset for sure. I cannot ground the housing of the switches. I've put a TVS (fast zener diode) on each data line, but that doesn't seem to work.





How can I protect the device against ESD strikes? Would series resistors help for i/o lines?

2. Bad MCLR circuitry
I doubt that this causes the problem, however my MCLR circuitry is not like it should be (decision from upper hand):



C27 (1uF) is not stuffed (this made my PIC unprogrammable). All these components are on the CARRIERboard, so very far away from the PIC. I'm planning on redesigning this circuitry. Can you give me some tips? Where do you place best the pullup resistor? How can I protect this line from noise and ESD?

On the PIC I have 2X100nF and 2X1uF close to it's power pins. It's powered by a TI 3V 100mA LDO with 4.7uF on its output.

3. My software causes the reset
I'm not a very experienced programmer, but I very much doubt this causes the reset, but in theory software can cause this. I have a bootloader.

My fuses are:

Code:
#include <16F877A.h>
#device adc=10 *=16 // meer geheugen
#fuses XT, PUT, NOWDT, NOPROTECT, NOLVP, NOCPD, NOWRT, NOBROWNOUT
#use delay ( clock = 4000000 )
#use rs232 ( baud = 9600, parity = N, xmit = PIN_C6, rcv = PIN_C7, bits = 8, ERRORS)


Can you experts give me some advice on solving the random reset problem? I can provide more info if you require.

tia!
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Jan 14, 2008 9:19 pm     Reply with quote

Do a search on ESD in the forum archives. There have been a few
threads on how to fix this problem.
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 2:05 am     Reply with quote

I'll do that; any advice on the other 2 points?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 2:16 am     Reply with quote

To prove if it's the PIC software, make a very simple program that
blinks an LED. Have it send a message to a terminal program at
power-up. You could also put in a check for "restart cause" at the
beginning, and display the results. You could also set all unused pins
to output a logic low level. (i.e., don't leave them set as floating inputs).

Let the program run for a day. See if any restarts are reported.

If you're still getting resets, then it's probably a hardware problem.
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 2:27 am     Reply with quote

What are your tips on the MCLR circuitry?
Ttelmah
Guest







PostPosted: Tue Jan 15, 2008 3:50 am     Reply with quote

Some comments.
If your unit is 3.3v, then you should be using the PESD3V3S2UT devices, not the 5v units...
There is a big caveat, with all this, how are the grounds of the protection devices connected?. Remember the energy they are clamping, has to go somewhere, and if this elevates the ground rail on one board, though they will generally still protect against _damage_, system resets are still likely to occur.
Remember also, that these devices are primarily designed to prevent damage the clamping voltage will still typically be high enough to cause problems. Clamp signals with these at _source_, then have a series resistor, and small capacitor, close to the PIC input itself. These can be small (1KR, and 100pF for example), but serve to massively attenuate fast edges on the signal. Consider writing your code to restart unnoticeably, and using the restart_cause test to do this, rather than a normal boot.
Add a 'restart_cause' test to the code, and see what it reports, when one of the resets occurs. If it is saying 'MCLR reset', then start looking at the MCLR circuitry, but if it reports something else (BROWNOUT etc.), then possibly the supply itself is being spiked, or the ground elevated.
Here consider re-installing C27, but making it smaller (that it stops programming, means your programmer is not generating Vpp properly with it present - test and see what is happening - possibly ringing on this rail), again put this close to the PIC. Also have R25 on the PIC board, not on the remote board. As it stands, anything induced on the wires between the boards, is hardly being attenuated at all, and going straight into MCLR...

Best Wishes
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 5:17 am     Reply with quote

Ttelmah wrote:
Some comments.

thanks, appreciate all your replies!

Quote:

If your unit is 3.3v, then you should be using the PESD3V3S2UT devices, not the 5v units...

VPic = PIC supply voltage is 3.0V. I'll be using the 3V3 units in the future.

Quote:

There is a big caveat, with all this, how are the grounds of the protection devices connected?. Remember the energy they are clamping, has to go somewhere, and if this elevates the ground rail on one board, though they will generally still protect against _damage_, system resets are still likely to occur.

Well, this is exactly what happens I think. I made a picture of the ESD current (clamped energy) path:



1. spark on button
2. current goes onto input (and/or?) output line. This causes a PIC reset (so probably a brownout)
3. Current goes through the 5V2 zener, through a thick track on the switches-PCB
4. Current goes through 1 pin of the board to board connector.
5. Current goes through a thick isolated track to a ring. This ring is connected to the keyboards ground plane with 8 via's (perhaps this is not good?)
6. Current goes through a metal washer to the CARRIER-pcb
7. Current goes via ring (connected to carrier's ground plane) to the metal backplate (back of the housing)

What am I doing wrong here? Why are the zeners not working? What can I do to improve/achieve ESD immunity? Should I use more ground planes on top and bottom layers?

Quote:

Remember also, that these devices are primarily designed to prevent damage the clamping voltage will still typically be high enough to cause problems. Clamp signals with these at _source_, then have a series resistor, and small capacitor, close to the PIC input itself. These can be small (1KR, and 100pF for example), but serve to massively attenuate fast edges on the signal.


So you would suggest: clamping diodes close to the switches (as it is now) and an R-C (1000k - 100pF) network on each switch-input line of the PIC?
Why close to the pic? Shouldn't you filter noise etc right at the source of it?

Quote:

Consider writing your code to restart unnoticeably, and using the restart_cause test to do this, rather than a normal boot.
Add a 'restart_cause' test to the code, and see what it reports, when one of the resets occurs. If it is saying 'MCLR reset', then start looking at the MCLR circuitry, but if it reports something else (BROWNOUT etc.), then possibly the supply itself is being spiked, or the ground elevated.
Here consider re-installing C27, but making it smaller (that it stops programming, means your programmer is not generating Vpp properly with it present - test and see what is happening - possibly ringing on this rail), again put this close to the PIC. Also have R25 on the PIC board, not on the remote board. As it stands, anything induced on the wires between the boards, is hardly being attenuated at all, and going straight into MCLR...


The 1uF and 390Kohm were originally used as an RC filter as protection to ESD sparks on the MCLR line. But the cap caused problems
(Well with the 1uF, I could program, but then I would find the PIC incorrectly programmed, being unable to reprogram it without the capacitor).
I'll put 10 nF on the MCLR, close to the PIC.
Isn't it a problem to have a 82 ohm pullup instead of of normal 47K?

regds
Ttelmah
Guest







PostPosted: Tue Jan 15, 2008 5:28 am     Reply with quote

You can pull up with anything you want. The 'problem' with smaller pullups, is that when Vpp is applied to the PIC, few programmers can drive much below perhaps 20KR. However on your circuit, the 390K, prevents the low pull-up being a problem.
Yes, you always wan't to block ESR, as close to the source as possible. However the TVS diodes should already be doing this (are you using TVS diodes, or zener diodes? - you refer to zeners in your latest post - zeners are generally too slow, for good transient protection). However once the signal is 'blocked', there is then still the overshoot as the suppressor clamps, and any signals induced along the linking cables. These then need to be blocked after these cables, hence close to the PIC.
How is the PIC's ground related/connected to your 'protection' ground?.
5.2v for a clamp is way too high for a 3.3v PIC. Max voltage on any pin, will be about 4v. The internal diodes in the PIC, will be doing all the clamping, before the zener/TVS, starts to work...

Best Wishes
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 9:11 am     Reply with quote

Ttelmah wrote:
You can pull up with anything you want. The 'problem' with smaller pullups, is that when Vpp is applied to the PIC, few programmers can drive much below perhaps 20KR. However on your circuit, the 390K, prevents the low pull-up being a problem.
Yes, you always wan't to block ESR, as close to the source as possible. However the TVS diodes should already be doing this (are you using TVS diodes, or zener diodes? - you refer to zeners in your latest post - zeners are generally too slow, for good transient protection). However once the signal is 'blocked', there is then still the overshoot as the suppressor clamps, and any signals induced along the linking cables. These then need to be blocked after these cables, hence close to the PIC.


OK, thanks for this explanation.
As my matrix is 9 X 8, I will be having 9 X RC network close to the PIC. But there is not much space there, unless I use 0402 resistors/caps. How close is "close" to the PIc actually? ( what is the max distance allowed for "close") ?

What other influence can a RC (1000k - 100pF) have on the inputs of my keyboard matrix? Isn't it so that normal keypresses will be detected a little later?

Quote:

How is the PIC's ground related/connected to your 'protection' ground?


Well, as you can see on the picture, the "ESD ground" is connected to the keyboard's ground plane (=PIC ground, PIC is the keyboard) where the pink arrow is. The ring is connected to the PIC's ground plane with via's. 3 boards are stacked. The keyboard and the cursorrouting (pcb with switches only) are connected to the carrier (see blue arrow).



Quote:

5.2v for a clamp is way too high for a 3.3v PIC. Max voltage on any pin, will be about 4v. The internal diodes in the PIC, will be doing all the clamping, before the zener/TVS, starts to work...


So the reset might also occur because 5V2 is put on an input?
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 9:23 am     Reply with quote

Ttelmah wrote:
Quote:

Add a 'restart_cause' test to the code, and see what it reports, when one of the resets occurs.
If it is saying 'MCLR reset', then start looking at the MCLR circuitry, but if it reports something
else (BROWNOUT etc.), then possibly the supply itself is being spiked, or the ground elevated.


Did you make such test?
It is a very important test to have the right clue to know to whom to fight.

Humberto
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 9:38 am     Reply with quote

Not yet today, too many other work. I will start it tomorrow and let it run for 24 hours.

I've tested ESD on the buttons (have home-made ESD gun) and that makes the PIC reset for sure. Will check restart_cause () 's argument tomorrow.
Ttelmah
Guest







PostPosted: Tue Jan 15, 2008 10:31 am     Reply with quote

1K, not 1000K.
Time, under a uSec. In fact it might be worth going to 1000pF. Larger values here, will slightly help to handle debounce on the switches.
On the board with the PIC, with a solid ground between.
Loks as if the boards don't have any ground plane?. If so, this would help massively, and remember that with a little care in the tracking, ground and power planes that are nearly as good as those on dedicated layers, can be produced on the existing tracking layers...

Best Wishes
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 10:42 am     Reply with quote

Yes 1K offcourse... don't think 1000K would give me any keypress :\

Keyboard and carrierboard are 4 layer pcb's. So they each have a separate ground plane. (layer stackup: top, ground, routing, bottom) The cursorrouting (pcb with switches) is a 2 layer board; so no ground plane.

The ESD track (= ESD ground) is connected to the keyboard's ground plane (via's - see red arrow). Is that OK ? Or should it be connected directly to the metal backplate?
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 12:37 pm     Reply with quote

In your MCLR circuit I don´t understand what is the reason for use such high value
in R25 (390K). This will impose a low MCLR biasing which will result unsafe and
prone to autoreset.
According to the datasheet, it should be >1K (that doesn´t mean 390K) Cool


Humberto
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Tue Jan 15, 2008 1:21 pm     Reply with quote

Some comments. Ground planes are a very good thing, especially on 2 layer boards. My 2 layers are routed as follows: signals first, power second, then I fill all unused areas with copper. All ground pins get connected to this copper fill, and the fill itself is connected, top layer to bottom layer, with vias. Any small fill areas that I can't connect to the rest of the ground plane, I delete.

Inputs. It's my standard practice to include ferrite chokes, and they come first in the chain. The chokes are there for EMC/EMI. Following the chokes is the protection. Either a discrete TVS or a packaged one, such as the Littelfuse SP721. As others have told you, it's important to match the rated clamp voltage to your supply rail.

Series R. Now comes a series resistor. It's there to add a degree of protection between a TVS that is conducting (and will be at its clamp voltage, which WILL be higher than your rail), and the chip you're protecting. If there is a possibility that the customer can erroneously put a wrong wire in that input (ie switch power for input), the resistor should also be sized (R and power rating) to withstand such an event.

Last comes a capacitor to ground. I use 10nF/50V. This is partly for filtering, partly "tank" protection. I say tank because I keep coming back to my undergrad engineering profs and their analogy that a capacitor = empty drum/tank. Pour water into the tank, and the level of water inside it goes up. This is equivalent to "pouring" charge into the capacitor, which will cause the voltage across it to go up. In my thinking, if any charge makes it past the upstream protection, the capacitor will help to smooth it out.

Your final line of protection is the PIC's input itself. Its internal diodes to Vcc and ground will help to clamp whatever makes it there.

I designed an automotive product with this same protection scheme and my customer has inadvertently tried to fry it about 50,000 times. So far, he has failed. People can get really creative when it comes to the question of "how can I possibly screw this up?" For example, putting power cables where the signal/switch cables should go, mixing power supplies (there are a mix of 5V and 12V sensors on this thing, and they've powered the 12V sensors from 5V and vice-versa, which meant that the signal conditioning inputs that expected to see 5V max actually got 12), and of course ESD and the generally nasty crap that gets thrown out by an automotive 12V supply.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group