Post by thread:[PIC]: PIC hanging?

Hi, I have a 16F628 based circuit that is used to monitor the water level, and then operate a 240 volts, 3phase pump depending on the level conditions. The software logic seems all right, and the unit works the way it is supposed to. But, at times (about once a week) it behaves erratically. Since the installation site is quite remote, I have not been able to determine what the status is when the circuit misbehaves (as in, whether the PIC has hung, or whether at this point it is not responding to the inputs). The only way out in this situation is to reset the unit. I have simulated all possible combinations of the inputs, and they work flawlessly, ruling out a logic issue. I've disabled MCLR, yet connected it to +5 to eliminate erratic resets. Incidentally, the power supply is derived from a 480 volts transformer, with the primary between 2 phases; this is because there is often no neutral brought in into the pump house.The secondary has the usual full wave rectifier, a filter (470 uF) followed by a 7805 and a decoupling 0.1 uF. First, does this problem look power supply related? (I suspect it is) If it is, what could be a cure? A more elaborate design with a Pi filter, perhaps? Or could it be anything else I am overlooking? Please HELP! Regards, Anand Dhuru -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> Since the installation site is quite remote, I have not been able to > determine what the status is when the circuit misbehaves (as in, Assuming it's not PSU-related - How about saving variables etc to EEPROM if the PIC either sees or causes an event. That way you'll have some kind of "black box" record. I've fixed something similar in a job. The fault was traced to an unintentioned skip over an instruction that reset a variable. It only happened under certain uncommon circumstances Or you could try a second PIC to monitor and log conditions that the first is seeing on its pins. The first PIC puts out a frequent "I'm OK" signal. On cessation of this signal the monitoring PIC stops logging Is the PIC inside a shielded box with filtered cables ? The trouble might be airborne -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

On August 12, 2004 10:22 pm, Anand Dhuru wrote: > Hi, > > I have a 16F628 based circuit that is used to monitor the water level, and > then operate a 240 volts, 3phase pump depending on the level conditions. > > I've disabled MCLR, yet connected it to +5 to eliminate erratic resets. Likely a power supply or voltage spike problem. Possibly a long-run on your ports (if you got several feet of trace wire going directly to your ports, you may be inductively reseting the PIC). Add inductors to your PIC power lines to kill voltage spikes. Add inductors to your PIC inputs/outputs to kill voltage spikes. If this is a 1-of-a-kind circuit where you don't plan on building more, simply cut traces, use an X-acto knife to scratch the paint off the related traces, then solder the inductors onto the traces over the gap.... assumming you have no other locations to place inductors. I've dealt with some low voltage circuits where adding the PIC watchdog circuit plus PIC brownout circuit helps. Watchdog because a voltage glitch may make the program counter jump unexpectedly. Brownout because sometimes the voltage rises too slowly, so although reset works correctly, the chip isn't exactly fully functional since it isn't at a "good enough" operating voltage. Short of those suggestions, you may have to add an external rest circuit such as a 555 timer type circuit if you are still in trouble. You keep reseting the external 555 using one of the PIC port-pins so that it doesn't reset your PIC chip. -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

Thanks Jose, Jinx, > Likely a power supply or voltage spike problem. > Possibly a long-run on your ports (if you got several feet of trace wire > going directly to your ports, you may be inductively reseting the PIC). I do; the sensor cable can be in tens of feet; typically 80. > Add inductors to your PIC power lines to kill voltage spikes. At the input of the 7805? or the output? What value? > Add inductors to your PIC inputs/outputs to kill voltage spikes. What value? > If this is a 1-of-a-kind circuit where you don't plan on building more, > simply cut traces, use an X-acto knife to scratch the paint off the related > traces, then solder the inductors onto the traces over the gap.... assumming > you have no other locations to place inductors. No problem here. > > I've dealt with some low voltage circuits where adding the PIC watchdog > circuit plus PIC brownout circuit helps. Watchdog because a voltage glitch > may make the program counter jump unexpectedly. Brownout because sometimes > the voltage rises too slowly, so although reset works correctly, the chip > isn't exactly fully functional since it isn't at a "good enough" operating > voltage. Could you elaborate the above again, please? I somehow thought evoking the brownout would make matters worse. > > Short of those suggestions, you may have to add an external rest circuit such > as a 555 timer type circuit if you are still in trouble. You keep reseting > the external 555 using one of the PIC port-pins so that it doesn't reset > your PIC chip. > Thats a great suggestion. If nothing else works, I'll do this. This option I'll keep for the worst case, as I'll have to redesign the PCB. The technique does sound great! Thanks again, guys. Anand Dhuru > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu ---------------------------------------- My Inbox is protected by SPAMfighter 548 spam mails have been blocked so far. Download free http://www.spamfighter.com today! -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

> > you may have to add an external reset circuit > Thats a great suggestion. If nothing else works, I'll do this Yes, it's a good suggestion and may stop your PIC locking up, which would be quite OK in possibly many applications, but if it were me I'd like to find the reason for the hanging. Hate unfinished business, but I appreciate the difficulty you have finding out what's causing it to hang My guess would be the 240V switching. How's that being done - relay, solenoid, triac, other ? Would it be possible to run it off a battery (eg a gel cell) for a while and maybe even opto-isolate the sensor ? May help to pin down the fault On the other hand, if this is a one-off and it really really really does work, then screw it, get it going and move on -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

> the sensor cable can be in tens of feet; typically 80 Maybe a 4-20mA loop for signal rather than whatever it is now - voltage , resistance ? Often used in noisy environments You could add a reverse-biased diode to ground at the input to the 7805, with a filter cap (say 470uF + 0.1uF) to ground at the i/p too. That should clean up some noise Also, series resistor (100R or so) between 7805 and PIC, plus a filter cap (also 470uF + 0.1uF) on the PIC side. Add a diode from o/p (anode) to i/p (cathode) of the 7805. This prevents the 7805 o/p being higher than the i/p if there's a short on the i/p (see 7805 data sheet) -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

i also had problems with hanging pics, and i found out this was because of emc on the relatively long sensor cables. when you get too much current from a pic's i/o, the output driver is disabled and you need a powerup of the pic to get the driver 'alive' again. as I usually pull about 20ma from the pin, and the driver shuts off at about 25ma, this occurred about twice a month, whenever I get some additional rubbish on the sensorline, increasing current to more than 25ma. as I did not find an easy and reliable solution for this, I did the following workaround: just using the internal watchdog does not help, as it only resets the pic's core, but not it's output buffers and the periphery chips. so I added a relais to the power supply of the whole circuit, which powers the circuit in it's off state. when the pic starts, it checks eeprom address 0: if it has value 0, it overwrites it with 1 and continues in program execution. if it has value 1, it overwrites it with 0 and turns the relais on, unpowering the whole circuit. this enforces a cold-start every 2nd time, the pic starts up. like this, I get a cold-start of the whole circuit immediately after the pic gets hanging. the only thing you have to make sure is that you have all configuration data in the eeprom, as ram memory data may contain new data after a cold-start. tino -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

> Yes, it's a good suggestion and may stop your PIC locking up, > which would be quite OK in possibly many applications, but if > it were me I'd like to find the reason for the hanging. Hate > unfinished business, but I appreciate the difficulty you have > finding out what's causing it to hang I agree; ideally, I'd love to get to the root of the basic problem too > > My guess would be the 240V switching. How's that being done - > relay, solenoid, triac, other ? > A small relay that in turn drives the 3 phase motor starter coil. > Would it be possible to run it off a battery (eg a gel cell) for a > while and maybe even opto-isolate the sensor ? May help to > pin down the fault Because of the frequency of occurrence, I dont think this would be practical. I was toying with the idea of using the battery as a supplement to the 7805 supply, to clean out the DC at my most desperate moment, though. > Maybe a 4-20mA loop for signal rather than whatever it is > now - voltage , resistance ? Often used in noisy environments The 'sensor' is actually a PWM out from the pic galvanically isolated (cap in series at the output, and in series at the inputs), returning to the input pin thru' the water body. No DC content in the current, works great. > > On the other hand, if this is a one-off and it really really really > does work, then screw it, get it going and move on > Unfortunately, it is not! This is a pilot installation, many more would be hopefully made once I sort out the issue! Regards, Anand > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu ---------------------------------------- My Inbox is protected by SPAMfighter 549 spam mails have been blocked so far. Download free http://www.spamfighter.com today! -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

> Because of the frequency of occurrence How often does the motor get switched ? Can you do many starts to eliminate that as a cause ? Is the relay on the same Vcc as the PIC ? It seems to me there are two suspects - the power supply and the sensors You know that the present set-up hangs, so add two more PICs with identical code. One is run off a separate clean supply (ie a battery) with sensors, the other is run on the mains supply with no sensors. If either of them hang then that may give you a clue It sounds as though the sensor **may** not be the problem if it's PIC-driven and PIC-received. So disconnect the sensor and see what happens Short of that I can't think of anything else except logging > Unfortunately, it is not! This is a pilot installation, many more > would be hopefully made once I sort out the issue! Ooooh, bugger -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

Thanks, Jinx. Anand ----- Original Message ----- From: "Jinx" <RemoveMEjoecolquittTakeThisOuTCLEAR.NET.NZ> To: <PICLISTEraseME.....MITVMA.MIT.EDU> Sent: Friday, August 13, 2004 5:49 PM Subject: Re: [PIC]: PIC hanging? {Quote hidden}> > Because of the frequency of occurrence > > How often does the motor get switched ? Can you do many > starts to eliminate that as a cause ? Is the relay on the same > Vcc as the PIC ? > > It seems to me there are two suspects - the power supply and > the sensors > > You know that the present set-up hangs, so add two more PICs > with identical code. One is run off a separate clean supply (ie > a battery) with sensors, the other is run on the mains supply with > no sensors. If either of them hang then that may give you a clue > > It sounds as though the sensor **may** not be the problem if it's > PIC-driven and PIC-received. So disconnect the sensor and > see what happens > > Short of that I can't think of anything else except logging > > > Unfortunately, it is not! This is a pilot installation, many more > > would be hopefully made once I sort out the issue! > > Ooooh, bugger > > -- > http://www.piclist.com hint: To leave the PICList > EraseMEpiclist-unsubscribe-requestmitvma.mit.edu> ---------------------------------------- My Inbox is protected by SPAMfighter 549 spam mails have been blocked so far. Download free http://www.spamfighter.com today! -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

On August 13, 2004 01:41 am, Anand Dhuru wrote: > Thanks Jose, Jinx, > > > Likely a power supply or voltage spike problem. > > Possibly a long-run on your ports (if you got several feet of trace wire > > going directly to your ports, you may be inductively reseting the PIC). > > I do; the sensor cable can be in tens of feet; typically 80. This is probably your problem then. You have an input antenna. Try shielded cable. Preferably twisted-pair. Not sure what you want to put on inputs, depends on speed. If really slow sense, probably try resistor between cable and input, with cap across input to kill spikes, guess maybe 1k to 10k, choose T=RC to suite your circuit. You're making a low-pass filter on inputs. You'll have to do similar on outputs going on long runs. choose an R large enough to kill spikes, yet small enough to do the work. C to suite for your T=RC If GND on inputs/outputs does not have to be "ground" at far end, add resistors on ground side as well so you don't have current loops or other nonsense sent via GND line. You have a poor circuit design if you need to ground the far side (imagine far end getting yanked up-n-down several volts due to spikes). Inductors might be are more effective. > > Add inductors to your PIC power lines to kill voltage spikes. > > At the input of the 7805? or the output? What value? If power comes thru a stepdown transformer, it is an inductor. If switching power supply, you might want to put the inductor in front of cap leading to 7805. you may need to add cap in front of inductor to compensate (basically making a low-pass filter). > > Add inductors to your PIC inputs/outputs to kill voltage spikes. > > What value? XL = 2 x PI x 60 x L (does 1...10mH look okay?) > > may make the program counter jump unexpectedly. Brownout because > > sometimes the voltage rises too slowly, so although reset works > > correctly, the chip isn't exactly fully functional since it isn't at a > > "good enough" operating voltage. > > Could you elaborate the above again, please? I somehow thought evoking the > brownout would make matters worse. If you have a variable voltage supply, try slowly cranking up the voltage by hand. Some chips won't start correctly. Try again with brownout enabled. > > Short of those suggestions, you may have to add an external rest circuit > > such > > > as a 555 timer type circuit if you are still in trouble. You keep > > reseting the external 555 using one of the PIC port-pins so that it > > doesn't reset your PIC chip. Forgot to add, you'll need to do it thru a cap - imagine lock-up if pin frozen in 1 state. Sending reset thru a cap won't matter if PIC freezes in bad state. > Thats a great suggestion. If nothing else works, I'll do this. This option > I'll keep for the worst case, as I'll have to redesign the PCB. The > technique does sound great! If one-of-a-kind, you can build it on a breadboard, use thin wirewrap-type wire to connect to reset, VCC, GND and PIC-pin. Use something stiff to stand it above main board - if nobody is going to be looking at or touching it, you may even use 1/4watt resistors as standoffs since board isn't that heavy - electricity doesn't care how ugly a board looks. If it's going to be viewed, do something that looks nice-n-professional. -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu

I, like others, would suspect the signal cable. An input pin to a PIC should not be connected to a long wire (aka antenna) without some external signal processing. A quick and easy fix to the problem would probably be to optoisolate the sensor at the pic end of the circuit. Working in high voltage areas with lots of electrical noise (motors and relays starting and stopping) is ripe for sudden spikes in antenna wires which can get past the protection built into the pic. Also, it appears in an earlier message that you are not using brownout - you should have that on if you suspect power supply problems. Any voltage too low to run the pic will automatically reset it. You might consider shielding the circuit itself. Use a metal box that's at the PIC ground, and don't extend any pic pins outside that box - if anything connects to the pic put it inside the box or condition the signal. Even pic output lines cause lots of problems when extended. Let us know how it goes, good luck! -Adam Anand Dhuru wrote: {Quote hidden}>Hi, > >I have a 16F628 based circuit that is used to monitor the water level, and >then operate a 240 volts, 3phase pump depending on the level conditions. > >The software logic seems all right, and the unit works the way it is >supposed to. But, at times (about once a week) it behaves erratically. > >Since the installation site is quite remote, I have not been able to >determine what the status is when the circuit misbehaves (as in, whether the >PIC has hung, or whether at this point it is not responding to the inputs). >The only way out in this situation is to reset the unit. I have simulated >all possible combinations of the inputs, and they work flawlessly, ruling >out a logic issue. > >I've disabled MCLR, yet connected it to +5 to eliminate erratic resets. > >Incidentally, the power supply is derived from a 480 volts transformer, with >the primary between 2 phases; this is because there is often no neutral >brought in into the pump house.The secondary has the usual full wave >rectifier, a filter (470 uF) followed by a 7805 and a decoupling 0.1 uF. > >First, does this problem look power supply related? (I suspect it is) > >If it is, what could be a cure? A more elaborate design with a Pi filter, >perhaps? > >Or could it be anything else I am overlooking? > >Please HELP! > >Regards, > >Anand Dhuru > >-- >http://www.piclist.com hint: To leave the PICList >RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu > > > > > -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

Hi Guys I wrote this program to read a value from PortB and send out serially at 1250KBPS but it's not working. can any of you see something that seems wrong. regards Luis ;*************************************************************************** * ;* OLink.ASM * ;* This program will be used on a 10MHz optical link * ;* * ;* ; WRITTEN BY LUIS MOREIRA ; REV: DATE: REASON: ; 1.0 13/08/04 INITIAL RELEASE ; this source file as been written for the PIC16F876 ;************************ IMPORTANT NOTE *********************************** ;to use RB3 as a normal I/O pin LVP(low voltage programming as to be disable(OFF) ; set config register __config _LVP_OFF & _HS_OSC & _WDT_OFF & _PWRTE_ON & _BODEN_ON & _DEBUG_OFF list p=16F876 include "P16F876.INC" org H'0000' goto start ;--------------------- EQU's --------------------------------------- ;------------------------------------------------------------------- start org H'0010' ; to miss interrupt vector and reset vector ;------------------PIC SETUP FOR COMMS----------------------- ;setup the pins on PORTA for serial comms main banksel TRISC movlw H'00C0' ; Sets Pin RC6 & RC7 as inputs movwf TRISC ;setup of SPBRG register banksel SPBRG movlw H'0000' ;THIS IS FOR 1250.000 Kbps WITH 20MHz movwf SPBRG ;setup of TXSTA register banksel TXSTA movlw H'0024' movwf TXSTA ;setup of RCSTA register banksel RCSTA movlw H'0080' movwf RCSTA ;--------------------PORT SETUP------------------------- ; PORTA WILL BE USED TO HANDLE EXTERNAL CONTROL i.e DAC banksel TRISA movlw H'0000' ; Sets all Pins as outputs movwf TRISA ;banksel PORTA ;movlw b'00000001' ;movwf PORTA ; PORTB WILL BE USED FOR DATA INPUT FROM DAC banksel TRISB movlw H'00FF' ; Sets all Pins as inputs movwf TRISB ;------------------- ready routine ------------------- movlw b'01010101' call txch ;-------------------- tx loop --------------------- txloop call getdata call txch goto txloop ;------------------transmit routine------------------- ; TXIF is tested to check if TXREG is empty, ; if set data in w register is transfered to TXREG txch btfss PIR1,TXIF goto txch movwf TXREG return ;--------------------getdata------------------------- getdata movf PORTB,w return end -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestKILLspammitvma.mit.edu

Anand, I'm joining the "it's the sensor leads" bandwagon! :-) On Fri, 13 Aug 2004 17:08:06 +0530, Anand Dhuru wrote: >...< > The 'sensor' is actually a PWM out from the pic galvanically isolated (cap > in series at the output, and in series at the inputs), returning to the > input pin thru' the water body. No DC content in the current, works great. That's not galvanically isolated, just DC isolated! Interference is almost by definition AC - a fast spike of interference will go through both caps easily, and may be causing the problem. (And if the signal actually travels through the water, what if there are electric eels in the water? :-) Would your sensor system work if it was opto-isolated at both ends, so the maximum voltage reaching the PIC is not related to what comes up the wire? You would need a seperate, unconnected power supply for the sensor side of the Optos, of course, but this is probably easier to isolate from the PIC than the signals coming up the wire. Can you show us a circuit diagram, in case there's something causing it that nobody has thought of? Cheers, Howard Winter St.Albans, England -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

At 03:33 PM 8/14/2004 +0100, you wrote: >Anand, > >I'm joining the "it's the sensor leads" bandwagon! :-) In general, Don't bring any microcontroller wires off-board without adding series impedance and shunt capacitance or active devices. Isolation may not be required, but in severe situations it often helps. BTW, you can't blame the PIC for this, it is a design issue, so the PIC really should be given a reprieve from the punishment suggested by the subject line.. Best regards, Spehro Pefhany --"it's the network..." "The Journey is the reward" speffSTOPspamspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads