 |
 |
| View previous topic :: View next topic |
| Author |
Message |
daveh
Guest
|
| Static charge resetting pic |
 Posted: Sun Mar 16, 2008 9:26 pm |
 |
|
Hi, I'm using a PIC16F648A in a project and having some problems. The device has two inputs, a pushbutton connected to RA4 and a switch connected to RB0. There are outputs that drive mosfets that drive some LED's as well as some outputs that drive a 7-seg LED display. The device is battery powered.
The problem is that sometimes when you've built up a little static and press the push button the PIC resets. Using software I've been able catch this as sort of a work around but ideally I’d like to fix the problem. I noticed that RA4 doesn't have a clamping diode to Vdd but RA3 does, I wasn't using RA3 but had already made the PCB so I soldered the two pins together which did not seem to make a difference. One side of the push button is connected to Vdd, the other side to RA4 and a series resistor through an LED to ground (LED lights when button is pressed). Any suggestions would be greatly appreciated. |
|
 |
__baltazar__
Guest
|
|
| Posted: Mon Mar 17, 2008 12:55 am |
|
|
| I am suspecting that the switch bouncing is the culprit or the BOR because you are running on cells. But it would be helpful to post your code fragment and the simplified schematic. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Re: Static charge resetting pic |
| Posted: Mon Mar 17, 2008 5:51 am |
|
|
| daveh wrote: | | ...The problem is that sometimes when you've built up a little static and press the push button the PIC resets... |
Yes, that happens. You cannot expect the protection diodes to absorb every ESD spark and have the PIC just continue on as if nothing had happened. You just have to be careful. Wear a static discharge wrist strap during development, and in production design the physical enclosure to prevent ESD from reaching sensitive inputs.
Robert Scott
Real-Time Specialties |
|
|
__baltazar__
Guest
|
|
| Posted: Mon Mar 17, 2008 6:15 am |
|
|
| Quote: | | You cannot expect the protection diodes to absorb every ESD spark and have the PIC just continue on as if nothing had happened. |
Hi Scott, although I don't find it disagreeable, I have not seen in any microchip documentation that multiple ESD strike in any pin would trigger a hardware reset. All the diagrams included in their literature just show two clamping diodes in an I/O pin just connected to either VDD or VSS - no other physical connection to any part of the logic. Anyways, if you have a reference document for this , I would appreciate if you will post the link.
Cheers |
|
|
__baltazar__
Guest
|
|
| Posted: Mon Mar 17, 2008 6:18 am |
|
|
Sorry for addressing you thru your last name ... it should have been "Robert". |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Mar 17, 2008 7:33 am |
|
|
Let's make some comments about this.
The first thing to do, is to write a program, to see 'why' the PIC is resetting. Use the 'restart_cause' routine, and when the PIC starts, either send the output of this to a external device with RS232, display it if something is available, or if the only output is the LED's, write code to flash these in different patterns, according to what the routine has returned.
At this point, it is worth realising, that the ESD protection on the PIC, has really nothing to do with keeping the chip running. It's job, is to help the chip _survive_. To help prevent destruction of the internal components. What happens in terms of a running part, will depend on a huge range of things. The data returned by the restart_cause, will help to reduce the possibilities.
Now, possibility one:
How is the PIC actually supplied with power - you mention 'battery power', but not how this gets to the PIC, and how it is decoupled?. Is there a regulator?. What capacitors are round the PIC?. The key to understand, is that the protection diodes, route the incoming spike, largely to the supply rails. If these are not well decoupled, the result is a momentary massive increase in the supply rail voltage. Depending on how the MCLR pin itself is wired, you can then get a MCLR reset.
Next possibility:
If the chip is supplied with a regulator, depending on how this is done, and it's response time, the supply may momentarily shut down. In this case, a 'brownout reset' may be seen, or a normal power up.
Another possibility:
If the supply rail goes high enough, the chip may go into an overvoltage condition (PIC's are suprisingly rugged in this regard), and the internal memory may become corrupted. Result stack overflow reset, or just about anything else!...
Best Wishes |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Mar 17, 2008 10:09 am |
|
|
[quote="__baltazar__"] | Quote: | | ... I have not seen in any microchip documentation that multiple ESD strike in any pin would trigger a hardware reset... |
It is implied by the Absolute Maximum Ratings section at the beginning of the datasheet, which gives maximum voltages and fault currents on any pin. One or the other of these specs is almost certainly going to be violated in any ESD event. Any violation of these ratings means that all bets are off and the PIC might do anything, including reset.
Robert Scott
Real-Time Specialties |
|
|
__baltazar__
Guest
|
|
| Posted: Mon Mar 17, 2008 9:22 pm |
|
|
| Quote: | | It is implied by the Absolute Maximum Ratings section at the beginning of the datasheet... |
That is just your opinion Robert. I don't believe it is implied. The absolute maximum ratings is specified by Microchip under the pretense of "extended period" ( ie continous condition). ESD is a transient condition (not continous) with a duration of nano to milli seconds. In fact, a MOS or CMOS device is even more prone to damage when not connected to any circuit and exposed to ESD ( ie holding the chip with your bare hands after being "charged" from the environment). When connected to a circuit and energized, the pin capacitances are normally sufficent to filter common transient conditions ( ie the MCU enthusiast touching the pins). Anyways, I rest my case on the ESD topic. What I want to see is daveh's schematic and his debounce logic on the code. Remember, the intermittent reset occurs only when he presses the button. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Tue Mar 18, 2008 10:02 am |
|
|
| __baltazar__ wrote: | | Quote: | | It is implied by the Absolute Maximum Ratings section at the beginning of the datasheet... |
That is just your opinion Robert. I don't believe it is implied. The absolute maximum ratings is specified by Microchip under the pretense of "extended period" ( ie continous condition). |
That "extended period" phrase refers to "Exposure to maximum ratings", not "Exposure to conditions that exceed the maximum ratings". So the Absolute Maximum Ratings do apply to short term events too. The first part of the text is:
| Quote: |
NOTICE: Stresses above those listed under "Absolute Maximum Ratings" may cause permanent damage to the device. This is a stress rating only and functional operation of the device at those or any other conditions above those indicated in the operation listings of this specification is not implied.
|
I don't know how anyone could interpret the bolded text and conclude that the PIC won't reset when a spark is drawn that exeeds the Absolute Maximum Ratings.
Robert Scott
Real-Time Specialties |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Tue Mar 18, 2008 12:55 pm |
|
|
It will help a LOT if you can put a resistor, say 100 or better yet 1000 Ohms, between the source of the spark (the switch) and the PIC pin. It makes it much easier for the clamp diodes to do their job.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
F
Guest
|
|
| Posted: Tue Mar 18, 2008 1:17 pm |
|
|
Hi
Please check your LVP fuse setting, if not used turn it off!!!
//F |
|
|
daveh
Guest
|
|
| Posted: Tue Mar 18, 2008 4:16 pm |
|
|
Thanks for all the ideas.
This is powered directly off of (4) NiMH cells in series, no regulator, only a 100pf capacitor across the input.
I output the reset_cause() and it always returns '19' - MCLR_FROM_SLEEP.
This is mounted in a plastic enclosure, if I simply touch the enclosure when charged with a little static it resets (doesn't need to be close to the push button).
| Code: | #include <16F648A.h>
#fuses INTRC_IO,PROTECT,NOBROWNOUT,CPD,NOWDT,PUT,NOLVP
#use delay(clock=4000000)
#rom 0x2100={0}
#define AutoSleep 600000 // Automatically goto Sleep in AutoSleep x 0.5mS 600000=5min, 120000=10min
int32 SleepTimer=0;
#byte PORTA = 5
#byte PORTB = 6
short LastButtonStatus;
short glitch;
int Counter=0,LastCounter;
#bit SegA=PORTB.5
#bit SegB=PORTB.4
#bit SegC=PORTB.3
#bit SegD=PORTB.2
#bit SegE=PORTB.1
#bit SegF=PORTB.6
#bit SegG=PORTB.7
#bit Red1=PORTA.1
#bit Red2=PORTA.0
#bit Blue1=PORTA.7
#bit Blue2=PORTA.6
#define PB1 PIN_A5
#bit Blinky=PORTA.2
#bit PWR=PORTB.0
#bit SEL=PORTA.4
void SevenSeg(char ascii);
void SevenSeg_putc(char ascii);
void Sequence;
void Seq00();
void Seq01();
void Seq02();
void Seq03();
void Seq04();
void Seq05();
void Seq06();
void Seq07();
void Seq08();
void Seq09();
#INT_EXT
void ShutDown() {
}
#INT_TIMER0
void TIMER0_isr() { // Occurs every 0.5ms (RTCC_DIV_2)
BLINKY++;
SleepTimer++;
if(!PWR || SleepTimer>AutoSleep) Counter=255;
if(SEL!=LastButtonStatus&&SEL==1){
Counter++;
if(Counter>9) Counter=0;
SleepTimer=0;
WRITE_EEPROM(0,Counter);
}
LastButtonStatus=SEL;
}
void Sequence(short R1, short R2, short B1, short B2, int16 del){ // R1,R2,B2,B2 1=on 0=off, del = ms delay
int16 i;
if(!glitch) break;
Red1=R1;
Red2=R2;
Blue1=B1;
Blue2=B2;
for(i=0;i<del;i++){
delay_ms(1);
if(LastCounter!=Counter) break;
}
}
void main() {
set_tris_a(0b00111100);
set_tris_b(0b00000001);
Sequence(0,0,0,0,1);
disable_interrupts(INT_EXT);
disable_interrupts(INT_RB);
disable_interrupts(INT_TBE);
disable_interrupts(INT_RDA);
disable_interrupts(INT_TIMER1);
disable_interrupts(INT_TIMER2);
disable_interrupts(INT_CCP1);
disable_interrupts(INT_COMP);
disable_interrupts(INT_EEPROM);
ext_int_edge(L_TO_H); // init interrupt triggering for button press
SETUP_TIMER_0(RTCC_INTERNAL|RTCC_DIV_2);
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);
SleepTimer=0;
Counter=READ_EEPROM(0);
while(1){
if(Counter<200 && !glitch){
LastCounter=Counter;
printf(SevenSeg,"%u",Counter);
}
switch (Counter){
case 0:
Seq00();
break;
case 1:
Seq01();
break;
case 2:
Seq02();
break;
case 3:
Seq03();
break;
case 4:
Seq04();
break;
case 5:
Seq05();
break;
case 6:
Seq06();
break;
case 7:
Seq07();
break;
case 8:
Seq08();
break;
case 9:
Seq09();
break;
case 255: // Shutdown Requested
Sequence(0,0,0,0,1);
delay_ms(100);
if(PWR && (SleepTimer<AutoSleep)) break;
disable_interrupts(INT_TIMER0);
// if(!glitch) printf(SevenSeg_putc," good bye ");
printf(SevenSeg_putc," good bye %u",restart_cause());
printf(SevenSeg_putc," ");
clear_interrupt(INT_EXT);
enable_interrupts(INT_EXT);// turn on interrupts
glitch=1;
sleep();
disable_interrupts(INT_EXT);// turn off interrupts
if(PWR) printf(SevenSeg_putc," hi billy ");
Counter=READ_EEPROM(0);
set_tris_a(0b00111100);
set_tris_b(0b00000001);
enable_interrupts(INT_TIMER0);
glitch=0;
break;
default:
Seq01();
break;
}
}
} |
|
|
|
daveh
Guest
|
|
| Posted: Tue Mar 18, 2008 4:43 pm |
|
|
| I also tried placing a 4.7uF as well as a 33nF across the battery input with the same result. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Tue Mar 18, 2008 5:53 pm |
|
|
| Quote: |
This is powered directly off of (4) NiMH cells in series, no regulator, only a 100pf capacitor across the input.
|
Just an advice. Are you aware that once a noticeable low voltage of the NiMh bateries
is detected, your device should be turned off immediately to avoid polarity reversal?
| Quote: |
I output the reset_cause() and it always returns '19' - MCLR_FROM_SLEEP.
|
If this is the reporting cause, why are you looking for in the pushbuttons?
instead I would spot in the MCLR pin. You didn't mention how it is held in its expected level.
Are you programming using some ICSP device?
Humberto |
|
|
daveh
Guest
|
|
| Posted: Tue Mar 18, 2008 9:20 pm |
|
|
| Quote: | Just an advice. Are you aware that once a noticeable low voltage of the NiMh bateries
is detected, your device should be turned off immediately to avoid polarity reversal? |
This device flashes some LED's which stop operating below about 3v, which is slightly below the 1v/cell reccommended for NiMH. At this point the user will know it's time to recharge the batteries. The PIC will operate down to 2v however the timer will put it to sleep after 5min. If the device was left unused (in sleep) for a very long time you're right it could damage the batteries.
| Quote: | If this is the reporting cause, why are you looking for in the pushbuttons?
instead I would spot in the MCLR pin. You didn't mention how it is held in its expected level.
Are you programming using some ICSP device? |
I receive the same code '19' when the unit is "shocked" and when it exits from sleep correctly - the RB0 is pulled high. So I assumed this is the code I should get when RB0 is pulled high with the ext_int enabled.
MCLR is connected through a 1M resistor to Vdd. Maybe that's too high? I also noticed I don't have NOMCLR in the fuses. I just tried adding the NOMCLR and it seems to be a little less sensitive however it still does trigger sometimes.
I program using an OLIMEX ICD2 |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
