TMR0 stops working

I have made a Digital led clock using the following hardware :-
PIC16F84A (used it as i have many lying around)...
4X 9 volt led displays

The time keeping is managed by TMR0 and Instant Interrupts.
The problem is that the TMR0 suddenly (and randomly) stops incrementing while the chip is on. This may happen in a few hours or in a few days or even after a month.
The oscillator still clocks at 4 Mhz , the chip still keeps the display running (multiplexing), the time set buttons still work.

I have been trying to fix this problem from the past 1 and a half year, but nothing seems to work.
I tried using a 16F628A, still no luck.
Now i really need some help.
I have attached the complete source code and schematic.
Can someone please help me ? ? ?

PSU.JPG = power supply with battery backup
clock.gif = base circuit
12Volt Driver.bmp = modification for large led displays
clock.pbp.txt = main source code
DT_INTS-14.pbp.txt = Instant Interrupts subsystem

Hard to say for sure, but with it working for months at a time, I wouldn't suspect anything in the software.

A couple things I can see that might cause problems ...

You are charging the 3V batteries from a 12v source with only a diode and resistor in series.
That's going to overcharge the batteries severely, and I'm surprised they haven't blown up yet. Then when the voltage gets too high, it'll pass right through to VCC raising the voltage above the F84A's limit.

Then if main power is lost, the F84A will be powered by only 3.6V, which is below the 4v minimum for an F84A.

The F84A doesn't have a Brown-out detector, so it won't reset or anything when the voltage is too low.

Voltages outside the normal operating range can cause just about anything to happen (randomly).<hr>
Lowering the resistor value to MCLR, with a small capacitor to ground may help reduce spurious resets, if that's where it's coming from.

Also, this isn't part of the TMR0 problem, but you shouldn't have a switch on the same pins used for an output. It's a dead short to VCC when the switch is pressed. Maybe with some resistors in series to limit the current, but straight to VCC like that, not a good idea.

<br>

Thanks for that Darrel . . .
I've added a .1uf from MCLR to ground, 1k from buttons to VCC. Datasheet states minimum operating voltage is 2 volts. (http://ww1.microchip.com/downloads/e...doc/35007b.pdf)
Sometime back i have also run the clock from a 12 volt lead acid battery (with 7805).
After 3 days, the clock stopped incrementing time, though the display was being multiplexed and the input buttons responded fine.
16F628A also shows the same behavior.
I tried writing a piece of code that resets all TMR0 registers and variables when the time set button is pressed, but no matter what ,TMR0 doesn't seem to come to life until a powerdown reset is done.

I think i have found the fault...
Sometimes when i turn on the tubelight in my room, the clock resets or hangs or stops incrementing time,even tough i'm power it from a battery.
Does this mean that i have to provide RF shielding to the PCB ? ? ?

I have a similar problem with my breadboards, ... when I turn on the fluorescent light on my desk.

I pretty much ignore it (mostly because I can't fix it).

It doesn't seem to be related to proximity, but seems to be related to it being plugged into the same "Power Strip" as the project.

If I plug the project into the wall, and the light into the power strip, it doesn't happen.

Surely there's an explanation .. (that will surface real soon).
<br>

It happens even if i run the clock from a battery.
It sometimes locks up when i plug in the cellphone charger adapter.
Will decoupling capacitors or line filters help?

If you don't have decoupling capacitors, it could be a problem.

I usually put a .1uF (100nf) across the power rails for every 2-3 chips.
Some people say 1 cap per chip, but I think that's a little more than necessary.

You shouldn't need RF sheilding.
<br>

Decoupling capacitors don't seem to help . . .
Using the 16F628A with MCLR disabled while programming solves the problem (for now)...

Hi shahidali55,
If your display is large and has long wires , it may well be acting as an antenna, try decoupling caps on each output line going to it, as well as any inputs, also try hooking all ground connections to a single ground connection, as ground loops often cause electronic circuits to oscillate, That is what they used to do in high end audio gear.
HTH
JS

Hello Joe,
My display is large and there are a lot of long wires running around and there are 2 ground loops.
How should i add decoupling capacitors to the output and input pins ?

I have attached a few photos of the complete clock and PCB side. . .
(They may take a while to download)

Hi shahidali55,
On the perfboard I would probably run a buss wire lengthwise under the pic and from each pin I would add .o1uf or even .001 uf capacitors to the buss wire which is hooked up to ground, I think you are getting RF into the chip from the outputs, RF is funny, it sort of crawls on the outside of conductors and does funny things. AS for things like cellphone chargers emitting RF I guess it depends upon which country's emission standards they meet or fail to meet. You might try using 2 bypass caps, 1 from each leg of the Mains power to ground right at the outlet. Ferrite beads are useful to trap RFI on wires on the circuit board. Be sure they are made for that high of a voltage,otherwise they pop like firecrackers:) Some links on RFI:

http://www.edn.com/archives/1995/010595/01df1.htm
http://www.eham.net/articles/12139

16F628A has been running stable for 10 days now.(Tried doing all sorts of things to make it reset, but its immunity is really good).
So i guess the only solution is to stick with the 16F628A . . .

My problem is still very much alive.
I had turned off the clock for over a month.
Now the clock "locks up" within 48 hours.
It has locked up twice at 7 hours , 14 minutes (7:14).
The mux routine works fine but the ISR just stops updating timing registers.
(The varibles that handle this are bres_hi ,bres_mid ,bres_lo.)
(uC is 16F628A and TMR0 used ot keep time)

I'm still thinking it's related to voltage.

The device is being powered by 3.6V
But the 16F84A is only specified to work down to 4.5V

In post #3 you said the datasheet specifies 2.0V
But that's only for the 16LF84A

Edit: Doh! You're using the 628 now. Nevermind.
<br>

shahidali55,

Do you have an updated program?
I tried to compile the program from post#1, but it has too many errors.

It also has the pushbuttons on the same pins as the segments, and ASM opcodes in column 1.
<br>

Hello Darrel,
As you suggested in post 2, the battery now charges from output from the 5v regulator (through a diode and a 2.2k resistor). The voltage at the PIC never rises above 4.6v. I tested this system with a 20v DC supply and the voltage at the pic pins is still at 4.63 volts (after 48 hours of running).

I have attached a copy of the file with the required include (Instant interrupts) as a zip archive.
The pushbuttons are not a concern now since the primary function of the device itself
(i.e. keeping time) is not met.

Is ASM opcodes in column 1 bad ?

Quote:

---

Originally Posted by shahidali55

I have attached a copy of the file with the required include (Instant interrupts) as a zip archive.

---

I don't understand why you've modified DT_INTS-14 like that. There's no need.
I also don't like modified versions being posted on the Internet. Somebody will download it, it won't work, and then they'll blame me. :eek:

Quote:

---

Is ASM opcodes in column 1 bad ?

---

Yes! Very BAD!
ONLY Labels can go in the first column of ASM code.
This applies to lines using the @ sign too. There must be a space after the @. (unless it's a label)

With opcodes in column 1, the program won't compile. So that can't be the program you are currently running in the chip.

DT

Strange . . .
Compiles fine for me.
I have corrected the OPCODE in column 1 errors and attached another copy of the file.
Sorry for modifying DT_INTS-14 , it it your work and i respect that. I modified it in my frustating attempts to correct the resetting and locking up of the chip.
(still getting 3 warnings though)

That is Strange! Wouldn't compile here the way it was before.

I can't see anything in the program that would cause it to lock up.
So I put together a breadboard to see what I could see.

http://www.darreltaylor.com/files/DT...5_clock_25.JPG

click image for larger version

It's running on a 16F88 right now. Couldn't find my 628A.

I'll see if it makes it past 7:14 first.
Then set the time, and let it run.
Hopefully I can find that 628A by then.

I'll let you know if it locks up.

DT

Thanks DT.
That is one really neat breadboard.
Did you notice the hourly on screen animation?


Just after the two LOOKUP statements there is a tricky piece of code that used to blink the colon:-
;if bres_hi<8 then
; Segments.7=0
;else
;Segments.7=1
;endif
It is there in the code posted in #1.
The code in post #18 has this part commented. Hence no blinking colon.
But after 4 days of testing with this code (#18) everything seems to be fine.
Could the blinking colon code have caused the problem?
To blink the colon, i used to check a critical time keeping variable (bres_hi) of the 24 bit counter. I think if bres_hi was being read when an interrupt occured and the ISR tried to update the register, it got corrupted. Can this happen?

It is pretty neat isn't it? I'm actually thinking about hanging it on the wall just like it is. :)

It's still happily keeping time. No glitches so far.
I can't image that the blinking colon would have made any difference, but I'll uncomment it just for diligence sake.

Yup, I saw the animation. That's cute. Also saw the upside down digits that I can see in your previous pictures, were mounted that way. Accidental??
I commented out the extra Lookup and IF statement.

Still haven't found the 628A, but I don't think there's enough difference to matter.
I suppose I should put a battery in there and run it at lower voltages too.
<br>

Quote:

---

Originally Posted by Darrel Taylor

I'm actually thinking about hanging it on the wall just like it is. :)
<br>

---

Not a bad idea. A clock does always comes in handy.
The last 2 digits were put upside down so as to get a colon from combining the two dot points on the oppositely placed standard 7-segment displays. An extra lookup table was the overhead.
If the clock is loosing or gaining time, you can adjust bres_lo reload value in the ISR.
(+.25 sec/day = bres_lo - 8 , -.25sec/day = bres_lo + 8).

Running it on a battery down to 2.1v will be the ultimate test.
My chip seems to have no problem till 2.1v. Below that the oscillator stalls and below 0.9v the ram gets corrupted.

I try to make this clock, using 16F628A.
But I can't compile :( ... Why ?! Thanks in advance !

You might want to consider posting the code that you can't compile VS a huge screen capture..;o)

When using DT_INTS, you have to use MPASM for the assembler.

Those errors are from PM.

Thank You, Mr.Darrel. You are, of course, right ! I checked the box "use MPASM" and works fine now.