Printable View
How does a PIC handle a problem that locks up?
With my little loop program I noticed this happen. I thought WDT was there to reset the chip and get things going again? Is there some required code to make this happen or is there some other process I need to know about to prevent the program from just stopping and not starting again without my having to cycle the power to the chip?
Thanks.
Bart
can you post your code to see what can be the cause of lockup.
you can clear watch dog timer... not sure it will resolve the problem here. CLEARWDT or NOP can do what you need.
I could post a link to it later tonight. Since this is the first program I'm ever wrote for a pic I'm sure it will be bloated and embarassing for me to show it, but I'll see what I can do.
I also am thinking that perhaps the chip is just shot from repeated programming and erasing as I try to get things to work.
Bart
here is the link to the code:
http://www.t2.net/users/bartman/remotelink/critter.bas
I just tried this version and it is clearly not working as it should. Hopefully the code makes enough sense to look at that you can compare it to what it is <em>supposed</em> to do. In this case, it makes 5 pins high or low at various timings. What it is doing has something to do with port 0 I think. If I move my finger on and off that wire on the breadboard at that pin the LED fades from on to off so that's why I think it's now hardware.
for sure it's an hardware problem. Can be solved easy. Place resistors (1-10K) between all input pins and ground. This is happen because your pin is floating and sensitive to all voltage/current variant from your body/environement.Quote:
What it is doing has something to do with port 0 I think. If I move my finger on and off that wire on the breadboard at that pin the LED fades from on to off so that's why I think it's now hardware.
this will work. Unused pin must be tie to ground or VDD to avoid other problem(be sure to set TRIS to input). It happen to me few time to blow a PIC when testing in automotive noisy environement.
regards
The only input in on MCLR and it is already on a resistor. The rest of the pins (excluding +5 and ground) are all outputs. Nothing is floating.
It just started doing this and worked fine before. Probably still hardware, but I don't think a resistor is going to fix it.
Did you look at the code?
Bart
as i see this code... look at your IF THEN statements
RETURN statement are use with GOSUB. In this case theres no gosubs, so your program don't know where to return. simply modify asCode:time:
if time_pick < 13308 then time1
if time_pick < 26615 then time2
if time_pick < 39722 then time3
if time_pick < 52829 then time4
time_pick = 1500 : return
time1:
time_pick = 800 : return
this is suppose to fix your problemCode:if time_pick < 13308 then GOSUB time1
if time_pick < 26615 then GOSUB time2
if time_pick < 39722 then GOSUB time3
if time_pick < 52829 then GOSUB time4
can also do
if time_pick<13308 then
time_pick=800
endif
maybe less jumping between here, there, somewhere will be more easy to debug.
That may be sloppy however that code was there from the beginning when things worked. I can't use the IF...THEN...ENDIF in the basic version nor the IF...THEN... COMMAND in basic. Must be a label as it is just a glorified GOTO statement in basic.
That whole routine is being called from a gosub near the beginning so actually the return is valid. It just happens to be at the end of an IF...THEN statement within the subroutine. Not illegal. When it executes there is just one subroutine called and one return.
Remember, the pbc is very crippled when it comes to standard commands that should be included such as IF...THEN...ELSE and IF...THEN...ENDIF. Makes for sloppy programming to have to work around this limit.
I'm still thinking fried chip.
Bart
it's maybe too late here... time to sleep i gues BUT yep in fact code is suppose to work.. But as i see few time, you asked about OSCCAL... maybe your chip lost his OSCCAL value. May you put a midpoint value, let's say $80 and tell us what's happening now. maybe you can program this value with your programmer without changing anything in the code.
but i never try to remove OSCCAL in PB to see what's happening.... maybe will work anyway... i know it make no sense but....
what about if you remove assembly code at the begining for OSCCAL setting ??
what about if you try a simple blink program on all outputs... is it working or not. case not OSCCAL or fried chip is the cause... or suppply line under the minimum
The OSSCAL thing is remarked out for the time being since it doesn't work the way I need it to work (it keeps a pin low when I need it to be high from the start).
There is no calibration value on the chip. From what I can tell there never was one as even the first read didn't show one. What four digit value can I put in there just to test?
Generally, calibration is not critical. If it is one or two ms out no one would know or care.
I can try testing all the outputs again to see what they are getting. I'll do that tomorrow night. Heading off to bed now.
I'm also now wondering about the voltage regulator. It is running off 9 volts regulated down to 5 with a 1.5 amp regulator that is anything but undersized and I have noticed it is getting rather hot and rather quickly. In initial tests it ran for a long time with the thing barely warm and now it borders on hot to the touch. Just noticed this for the first time tonight. Since the circuit is running next to nothing for components the heat seems excessive.
Makes for frustration when something works then suddenly stops for no apparent reason.
Bart
@3ff place 3480 to tryQuote:
There is no calibration value on the chip. From what I can tell there never was one as even the first read didn't show one. What four digit value can I put in there just to test?
weird if regulator heat really much... can be the PIC which blow
I <em>might</em> have found the problem.
Right now I think it is that damn MCLR pin. I went back to a simple "blink" program and everything worked okay for a little bit then just stopped. Since this should be a "no brainer" program even for me I figured soemthing had to be wrong with the PIC.
I restarted it and everything worked fine again for a short time then died again.
I bumped the resistor on the MCLR pin and found the LEDs behaved badly. More moving on that resistor and I could affect the outcome.
So, I checked that whole area out and found there was no power to the resistor so I reseated all of that and things have been running fine now for 5 minutes.
I put back in my original program, but left it just blinking LED's without the multiplexer for the time being. Based on the output I am seeing through the LEDs the program is working as I wrote it.
Now, this raises all sorts of questions again about MCLR. I programmed it with MCLR=ON so there is no way it should have ran when there was no power at that pin, yet it did run for a short time. What's up with that? That pin will drive me nuts yet since it does not seem to behave the way everyone here says it should behave.
I still think I need to know how I incorporate some kind of reset in the program just in case it does crash. How do I do that?
Tomorrow I will wire the breadboard again to include the multiplexer. That should ramp up the heat on the regulator if it continues to behave as it has been. That will be the real test if it can run for 10 hours without burning out or crashing. The way things have been going I don't think I want to hold my breath.
Bart
since everything will be solder on a board, you'll not going to have bad contact... so don't need anything like that. ou cannot monitor something when the PIC is not able to run well by himself.Quote:
I still think I need to know how I incorporate some kind of reset in the program just in case it does crash.
always remind MCLR=ON You need resistor to +5Volts(<10K). In case the resistor is not there, the program may work or not, depending on the noise comming on this pin. If the noise is sufficient, the PIC may consider that you have place a kind of resistor to 5 volts. but it's not going to be stable and bugless.
maybe program with MCLR=OFF will be a safe way to avoid everything. If you don't need this pin, tie it to ground to avoid static discharge... anyway the usual CMOS care.
now about the heat... what type of 9 volt supply are you using, wall plug DC transformer, regulated...
I see you're using 7805, can be mount on a few cents heat sink or on the ground tab on your bread board.
I see often here in Canada DC wall plug transformer without any capacitor to the output... so a lot of ripple at the input of the regulator... maybe you get one of these !!!! simply add a large capacitor >1000 uF at the input this will maybe reduce the heat. If you can scope the supply line tell us what's looks like straight line or else. Can also 10uf + 0.1uf be added a the output of this regulator to avoid some oscillation.
Now, this raises all sorts of questions again about MCLR. I programmed it with MCLR=ON so there is no way it should have ran when there was no power at that pin, yet it did run for a short time. What's up with that? That pin will drive me nuts yet since it does not seem to behave the way everyone here says it should behave.
NEVER leave the pin floating... if you have enabled MCLR, it's either tied to Vdd (either directly or via a Resistor), or it's tied to an external Reset chip (see answer below).
I still think I need to know how I incorporate some kind of reset in the program just in case it does crash. How do I do that?
In 99.9999% of all cases WDT will handle it for you if you have it enabled (see Datasheet). WDT is another configuration word setting like MCLR. If this is not good enough for you, then I refer you to a device like a MAX705, 706, 707, 708, DS1221 etc etc
I left things running all night and this morning it was still churning out random numbers so the MCLR/resitor issue was clearly the problem. If it crashed then the WDT (which I had set to ON) handled everything the way it was supposed to and rebooted it. If I can remember I can read the eeprom tonight and see what number is there and that should tell me how many times it re-booted.
Clearly the MCLR pin can have issues. I'm sure the wire that was on it, but not getting any voltage was enough to throw it out of whack. I can see now why debugging an issue like that can make one lose hair!
I used a 9 volt battery for my overnight test, but generally use a wall transformer and that's when I notice the heat. It is a cheap one so more than likely it is missing the capacitor.
My final board will be running off 12 volts and I am making that little AC to DC board myself so it should have a nice clean output (I had one of my old teachers from high school give me a schematic and tips on how to properly build that board to give a clean output) and I plan on adding a heatsink to the regulator just in case and because there is plenty of room for one.
I'm also going to be 100% sure to get the proper values for the capacitors for the regulator itself from its datasheet. I just don't have them available without ordering (so I am using the closest I do have for now).
I'll see what happens tonight with the "real" test with the multiplexer in the works.
Bart