Mysterious Reset

[JoelMurphy]

Hello,

My current application is too specific to really get into in a forum post. I've got a complex circuit with cascading SIPOs and PISOs, which takes inputs from analog and digital sensors, and uses darlington arrays to drive relays.
My problem is that the controller has a habit of resetting itself frequently, but not so that you can tell what is causing the issue.
I'm running with a 16F819, and the code is tapping on the ceiling of memory.
At one point I had configured pin A.5 as input, and had a microswitch attached to it via about 15' of 16g lamp cord. I thought the problem was with the MCLR not configuring correctly in the code, so I switched it out and am now inputting the microswitch signal to an analog input [pretty chunky, I know], but I'm still getting the phantom reset.
I've debugged the physical circuitry until my eyes are crossed, and I don't have any problems there, evidenced by correct opperation, albeit with intermittent restart.
I have received a stack of 16F88, and will be using that chip for further development, as I'm in need of more memory.

I'm wondering if this rings a bell with anyone out there? I did notice that the problem subsided after I changed the pin confguration and set A.5 as MCLR.

I have a 1000uF cap decoupling the chip, with a 10K pulling MCLR high. My powersupply is from Mouser: 5V, 5A part# 552-PSA-25LS-050-R.

I will be plugging in the 'F88 tomorrow, and that might solve the issue... but still! What's going on?

Thanks for your help!
I've gotten much out of searching the forums for the past few months!

-Joel

[skimask]

Hello,
I have a 1000uF cap decoupling the chip, with a 10K pulling MCLR high. My powersupply is from Mouser: 5V, 5A part# 552-PSA-25LS-050-R.

I will be plugging in the 'F88 tomorrow, and that might solve the issue... but still! What's going on?

Thanks for your help!
I've gotten much out of searching the forums for the past few months!

-Joel

You might have a 1000uF, nice fat cap across the rails, and they might even be right at the PIC, but...do you have a small cap with low ESR right there also? Generally speaking, a 1000uF cap is more for power smoothing, not decoupling. The problem might be that the big ol' fat cap can't do it's job at high freq's because of high ESR...in other words, works at low freq's, not at high freq's. I'd (as well as others I'm sure) suggest putting a .1uf right at the PIC's power/ground pins, both sides (if you're using that sort of PIC, 40 pin types). I'd doubt if an 'F88 will solve your problem.
Also, you're driving relays. You might have enough juice coming out of your power supply to drive everything...steady state. But what about the instant that a relay closes? If your power supply can't handle the instantaneous load (which could very well be far above the steady state load), you get voltage drop (which the 1000uF should help with), and instant reset

And don't forget about putting a 'dump diode' across the relay coils. Without one, a relay can really screw with a power supply in unintended ways.
Let us know what happens...

[Darrel Taylor]

There are 4 bits that indicate what caused a RESET.

POR	Power-On Reset	PCON.1
BOR	Brown-out Reset	PCON.0
TO	Time-out bit	STATUS.4
PD	Power-down bit	STATUS.3

This table from the 16F818/819 datasheet shows the values of them after various reset conditions.
You can send them to an LCD or RS232 terminal to determine what happened.

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=1398&stc=1&d=117185912 4"></img>

BOR/POR must be set manually to detect a Brown-Out Reset. See datasheet section 12.9

Also, if changing the value of OPTION_REG in your program. Be aware...

Note: To avoid an unintended device Reset, the instruction sequence shown in the
“PICmicro® Mid-Range MCU Family Reference Manual” (DS33023) must be
executed when changing the prescaler assignment from Timer0 to the WDT. This
sequence must be followed even if the WDT is disabled.

My guess would be something to do with the relays. Possibly back EMF feeding to the power supply.

And, even though you've got a HUGE capacitor on the power. You should still have a 0.1uf cap from VDD to VSS as close as possible to the chip.

Another possibility is a Stack Under-Flow. An Over-Flow won't do it, but an Under-Flow (Return without a Gosub) can cause it to jump to address 0000. It looks like a reset, but isn't. But you can see that from looking at those 4 bits.

HTH,

P.S. That's pretty weird sending sound thru 4 different bushes.
<br>

[JoelMurphy]

Yeah, it's called Vegetable Mediation!

Thanks for the great advice. I'll put a .1uF cap on the rails right now, and if I'm still having trouble I'll debug those power bits... although, that sounds kinda cool. I might just do that anyway.

I'm driving the relays with ULN2004A Darlington Chip, so the charge should 'dump' through that ok.
I'll go over the power supply datasheet to check it's freq specs.
There may be something to the Stack Under-Flow...

Also, This reset problem only happens when the entire system is running. That is, the relays are actually driving motor control. When I'm testing the system [Controller goes through it's program, sending power to the 5V relays thru the darlingtons, which send power to the relays that control the motors, but not actually turning on the motors.] it works great!

Likely problem is the absence of a low ESR.

Thanks again!

[skimask]

Also, This reset problem only happens when the entire system is running. That is, the relays are actually driving motor control. When I'm testing the system [Controller goes through it's program, sending power to the 5V relays thru the darlingtons, which send power to the relays that control the motors, but not actually turning on the motors.] it works great!

That would lead me to believe that your power supply's output impedance is too high, voltage dropping out if only for a couple of milliseconds, something you'd probably miss even on a 'scope. Starting current for most motors is quite a bit higher than running current, even under load. Maybe try seperating the PIC's power supply from the motor's supply?

[JoelMurphy]

yes, skimask.
the powersupply that is running my controller is outputting 5V to the relays, and I'm also tapping into the 110VAC input to send power out to the motor relays.

Power to the motors themselves is 220VAC on a separate circuit.

Maybe I need to put the 110VAC to the Motor Relays on a diferent circuit? the problem is that the issue is still very intermittent. The system may run for 10 minutes without a glitch, it may run for 30 seconds before a glitch.

gotta admit, i didn't add the .1uF cap yet. just got done debugging my chip upgrade...

[JoelMurphy]

oh, also, the problem doesn't always manifest itself when the relay switches on. it could be that the motor relay is on for 10 seconds before it glitches, or there could be NO relays on at all, and then it glitches...

it's the nature of the beast, i guess. expecting that i could just wake up one morning and tame all the electrons and hold them under my sway...

joel

[skimask]

oh, also, the problem doesn't always manifest itself when the relay switches on. it could be that the motor relay is on for 10 seconds before it glitches, or there could be NO relays on at all, and then it glitches...

it's the nature of the beast, i guess. expecting that i could just wake up one morning and tame all the electrons and hold them under my sway...

joel

Looks like it might be time for you to post the code and the schematic. Otherwise, it's looking like a big ol' crap shoot at best...and then we all get nothing done.
Have you tried threatening all offending electronics with mass amounts of profanity?

[JoelMurphy]

I'm upgrading the problem to Phantom rating.

Update:
I placed a .1uF cap right on the +/- for the 'F88 [still have the 1000uF on there]
I purchased a rechargeable battery: +12V
I built a 5V Regulator with .1uF on IN and OUT [L7805CV 1.5A]
I am now supplying power from the battery to the logic circuit, including:
PIC16F88
74HC165 PISO CASCADE
74HC164 SIPO CASCADE
411GHR R NETWORK
ULN2004 DARLINGTON ARRAY
5V RELAYS [16A 240VAC CONTACTS]
VARIOUS SWITCHES AND DIALS

The reset problem persists. ratsass.

The motors are 220VAC 1.5Horse and drive belt conveyors.
I have tried running the program without power to the motors [power from chip to darlington, to 5V relays; 110VAC through those relays to the motor drive relays,no load on those relay contacts] and it is an unqualified success. At no point during tests that range from 2 cycles to 25 cycles does the 'F88 reset itself. Yet, when I run the program with power to the motors, I get an intermittent restart. Restart occurs anywhere from 2 cycles to 7 cycles, 7 being on the high end. Even when I'm running under battery power!

spooky.

I made sure that it's not a full moon, and I didn't see any witchcraft paraphenalia in the vicinity. I don't think anyone holds a deep grudge against me... except for B, but he's living in a different state, and in any case he would get back to me through a much different route.

I'm attaching the code in-line below. sorry not to add a link, but it's late.

The only consistency that I've observed is that the restart happens at the moment the conveyor motors are started. Sure, they will draw a heavy load... they have alot of resistance to overcome at startup. BUT I'M USING A BATTERY!

If you've got any smart ideas, helpful or otherwise, I'd love to hear them.
Already thought of EMF, moved wires around [though didn't shield with grounded foil..] and still a restart.

Code below, and yes I do use that many comments when I'm writing.
Links to photos and a schematic to follow tomorrow.

Oh yeah, I haven't debugged the status bits yet. I'm 98% that it's a power-down reset... could that still help? [duh, stupid question]


Thanks for your time
Joel

PS well, I just got an error from the forum that my post is too long...
I'll try to post it in another reply, otherwise it'll wait to tomorrow for a link.
And I only got ONE crossing page boundary warning!!!

j

[JoelMurphy]

got the link clicked ok.
here's the code

[skimask]

The only consistency that I've observed is that the restart happens at the moment the conveyor motors are started. Sure, they will draw a heavy load... they have alot of resistance to overcome at startup. BUT I'M USING A BATTERY!
j

And I assume the motors are kicked on by a relay...
Have you added a 'back EMF' diode across the relay's coils yet? The ULN2004 may have a back EMF diode built into them ( and I don't think they do), but I'm assuming that the ULN2004 isn't sitting right next to the relays either. Ya gotta have that diode in there. It's cause you pain. Have you thought about getting rid of the relays and switching over to a solid state relay?

[JoelMurphy]

the ULN2004 has clamping diodes built into it. I have not put diodes across the relays, and as I've said, the system works without glitch until I apply power to the motors.

I'll think about where I could put a diode...
j

[Darrel Taylor]

skimask,

A quick look at the datasheet would have shown that the ULN2004 does have Output Clamp Diodes. Datasheet boy.

Joel,

Maybe you need a snubber on the relay driving the contactors coil.
I use .022uF 400V and a 47ohm 1/2w resistor in series across the output, but then I'm using SSR's

Works good for all the contactors I've used.
<br>

[skimask]

skimask,

A quick look at the datasheet would have shown that the ULN2004 does have Output Clamp Diodes. Datasheet boy.

Joel,

Maybe you need a snubber on the relay driving the contactor.
I use .022uF 400V and a 47ohm 1/2w resistor in series across the output, but then I'm using SSR's

Works good for all the contactors I've used.
<br>

Ya I know, I just downloaded it and looked That'll learn me for not learnin' me...
But still, what if the '2004 isn't right next to the relays? What if it's on the PCB and the relay is X feet down the road on a cable.
Maybe an opti-iso would be the ticket in this case...still doesn't resolve the relay spike but it might isolate it a bit better...
How 'bout a decent cap across MCLR? If there's a pullup on MCLR, maybe it's being dropped out on occassion?

[Darrel Taylor]

Just wanted to add that skimask's idea of Solid State Relay's can also reduce that spike, by waiting for the Zero-Crossing point of the AC wave before turning on.

A relay can't do that, and may turn on at the peak of the AC, causing a very large spark and spike.
<br>

[keithdoxey]

Do you have MCLR tied to +5V directly or have you used a resistor ?

Or have you done what I did on a protoype board and forgotten it. My board had been in used for months as I was developing code and was working fine. I kept adding bits of code and other circuitry and then one day started getting spurious random resets.

I had forgotten a pull up on the MCLR pin and it was now triggering on noise picked up from the ratsnest of prototype wiring. fitted a 1K resistor and it has been fine since

[JoelMurphy]

OK OK OK

The 5V relay is about 1.5 inches from the ULN2004.
Darrel, what is the cap-resistor across the relay coil supposed to do?

I have a 10K R pulling MCLR high
I have a 1000uF cap across +5 and GND right at the chip, along with a .1uF there too.

I'm going in today to place diodes across the relay coils to see if that could solve the problem...

I imagine that some kind of back fluxing is the issue... but I don't understand how the spike could travel through the 'unconnected' parts of the relay, and how it could effect my battery powersupply...

Joel

[Darrel Taylor]

what is the cap-resistor across the relay coil supposed to do?

From what I understand, it limits the rate of change in the voltage across the contacts.

Here's a thread where someone had a similar problem. Snubber seems to have helped.
http://www.picbasic.co.uk/forum/show...hlight=snubber

[Jerson]

Joel

I am not sure if I can be of any help here. But anyway, here it comes.

- Have you looked at the Brown Out settings? Try to disable it for a while to see if that is the cause.

- another item you can miss out on is the layout of your board. May happen that the heavy current is flowing past your PIC and lifting the ground. I would expect the layout to follow this route if possible or else have a star point grounding
MCU -> ULN -> relay -> PS (ground / VCC) This keeps the heavy load near the Power Supply (PS)
In one case I had a problem where the layout was causing problems.

I dont know if you understand what I am saying. What has to happen is that the lowest ohmic path should be from PS to relay and then to the lighter loads.

Excuse me if these are lame suggestions and you have them sorted out

Jerson

[mister_e]

it's common to place a few hundred nF cap in parallel with the relay coils. For the contact, if you switch DC load, the link Darrel provide is nice.

If you switch AC load, you really want to switch them on the AC zero cross. This have tons of advantages.

[JoelMurphy]

There's a reason why I gathered you all here today...

I have to hand it to Jerson. The BrownOutTimer killed my resetting problem.
Also, props to Darrel for bringing up the Status bits. That was going to be my next step.

Virtual Beers all around!

Now What!?!
I plan on placing snubbers on all my relays, like you suggest. OR, might get into SolidState relays. One question on those: how do they know when the zero cross happens?? is this some kind of smart realay?

I'll be interested to test if the snubbers solve the problem if I enable the BOR, but if everything is working appropriately, is there any issue with running the 'F88 with its BOR disabled? I'm running with INTRC... does that make a difference?

I'm not too concerned about having a rock solid clock... my serial out is only to an LCD screen.

I've used this forum as a searchable database for about a year. Now I'm the one who gets to say: Thanks for the help! Responses are fast, reliable, and well considered... and you guys really saved my bacon on this one. today was THE day my control circuit HAD to work for a meeting. order another round!

Joel

[Jerson]

Woohoo Joel!

I just had my beer(eh - Coffee). Glad you could nail it to the brown out reset. But that's not it. What this means is that you are getting power dips that are causing the malfunction. these would be caused by the power surge needed to turn on the heavy motor loads. Turning off the BOD is not the correct solution, just a guide to the problem. Hope you can get the power dips fixed. I think the snubber networks are a _must have_

Jerson

PS : just gave me an idea(a whacky one) How about a Virtual container for the virtual beers. I guess, DT and MrE would have a room full of 'em.

[skimask]

PS : just gave me an idea(a whacky one) How about a Virtual container for the virtual beers. I guess, DT and MrE would have a room full of 'em.

Assuming the Forum software could handle it, you could (for example) add a column next to 'POSTS' when looking at the 'Members List' or something like that. Or maybe an auto-incrementing pointer.

But, what happens when somebody just starts handing out random beers?
Now we've got a bunch of virtually drunk PIC users discussing virtually nothing...not to mention P.U.I. oh boy...
(posting under the influence)

[JoelMurphy]

someone has beat you to it
http://beer.trash.net/index.php

a sidebar on the forum would be nice though. options could include: rotten eggs, tomatoes, a board with a nail in it...

So, if it's not healthy to run the PIC without the BOR, I'll have to design a good snubber. shouldn't be too hard. I'll also add the clamping doides, even though they are included in the ULN2004.

And if that's not it, i'll be back to talk you again.

Best,
Joel

[Darrel Taylor]

Well, come back and let us know, even if that was IT.

.