Problem with PIC 16F628A resetting intermittently

[hbalit]

I have a program where the 16F628A resets intermittently.

The program controls a remote heater using a Dallas DS18B20 temperature sensor.

Initilization:
The circuit breaker is turned on and a relay enegizes keeping the heater off for 30 seconds. The operator then walks to where the heater is which takes about 30 seconds.
The relay then deenegizes to turn the heater on and the operator can verify operation.
After 30 seconds the relay energizes and the heater turns off then then goes to the main part of program.

Main:
The heater cycles as it goes above or below the setpoints.

Problem:
The heater cycles about 15 times per day normally, but about once or twice a day the PIC will reset and go into the initilazation sequence and the continue operation. This is not good for the heater as short on sequences are not good.

Solutions tried:
Used various power supplies, different temperature sensors, shielded and unshielded cable, noise filters all without any change.

I am posting the program as perhaps my logic is not correct or out of sequence.

Any suggestions?


'************************************************* ************
'* Name : Base_new_5.bas *
'************************************************* ***************
' RA2 as DQ for DS18B20
' RB3 as output to 0AC5A
' for 16F628A
#CONFIG
__config _INTRC_OSC_NOCLKOUT & _WDT_ON & _LVP_OFF & _CP_OFF & _PWRTE_ON & _MCLRE_OFF & _BOREN_ON
#ENDCONFIG

'1 - RA2 - DQ for DS18B20
'2 - RA3
'3 - RA4
'4 - RA5
'5 - Vss
'6 - RB0
'7 - RB1
'8 - RB2
'9 - RB3 - output pin for OAC5A
'10 - RB4
'11 - RB5
'12 - RB6
'13 - RB7
'14 - Vdd
'15 - RA6
'16 - RA7
'17 - RA0
'18 - RA1

OPTION_REG.7 = 0 ' turn on weak pullups
CMCON = 7 ' comparitors off port set for digital
VRCON = 0 ' A/D Voltage reference disabled
TRISA = %00000100 ' A2 as input all others outputs
TRISB = %00000000 ' all are outputs

Comm_Pin VAR PortA.2 ' One-wire Data-Pin on PortA.2
Sign VAR BYTE ' +/- sign for temp display
RAWTEMP VAR WORD 'Read raw temperature from DS18B20
VeryCold VAR RAWTEMP.Bit11 ' Sign-Bit for +/- Temp. 1 = Below 0 deg C
Busy VAR BIT
SetPoint var byte
s var byte
setpointhigh var byte
setpointlow var byte


setpointlow = 5
setpointhigh = 7



high portb.3 'no power for 30 seconds
pause 30000
low portb.3 'power for 30 second to verify it is on
PAUSE 30000
high portb.3 'no power until requested
' s = 0

Main:
gosub Start_Convert ' get temperature reading
if VeryCold = 1 then 'if the bit is set then turn heater on for 5 minutes
low portb.3
gosub FiveMinute
endif
RAWTEMP = RAWTEMP */1600
RAWTEMP = RAWTEMP / 100 'convert to degrees C

if RAWTEMP <= setpointlow - 1 then ' on setpoint = turn heater on
low portb.3
gosub TenMinute
endif
if RAWTEMP >= setpointhigh then ' off setpoint = turn heater off
high portb.3
endif
pause 1000 ' wait 1 second
goto Main ' do it again

TenMinute:
for s = 1 to 10
pause 60000
next s
s = 0
return

FiveMinute:
for s = 1 to 5
pause 60000
next s
s = 0
return

Start_Convert:
OWOUT Comm_Pin, 1, [$CC, $44] ' Skip ROM search & do temp conversion
Wait_Up:
OWIN Comm_Pin, 4, [Busy] ' Read busy-bit
' pauseus 25
IF busy = 0 THEN Wait_up
OWOUT Comm_Pin, 1, [$CC, $BE] ' Skip ROM search & read scratchpad memory
OWIN Comm_Pin, 2, [RAWTEMP.LowByte, RAWTEMP.HighByte] ' OWIN can read in a BIT or a BYTE
return




Thanks
Harold

[Archangel]

Hello Harold,
I would suggest a couple of changes:
1. BOREN_OFF
2. eliminate all those LOOOOONG pauses by using for next loops with short pauses and big numbers
3. Try to keep subroutines succinct and make sure they terminate with return so you do not get stack overflow problems
I am not sure why you zero counter variables and never use the zero value counting 1 to 5, probably makes no diff but I would
count 0 to 4 just so as not to confuse myself.
#2 is so you can interrupt the loop if you ever need to lets say you add some LCD display as a result of a push button interrupt, you will not
have to wait 5 minutes for the loop to respond.

[Acetronics2]

From my experience in industrial control ...

1) mains is " not so clean " and a strong filtering + backup battery generally solve 99% of regulation problems.

2) use a hardware reset circuit like with a MC 33164P5 ...

3) use Hardware pullups and not "software" ones ...

4) a CRC check could be a nice idea ...

5) take great care of your line to the DS1820 ... ( see Dallas design ideas for rugged nets ... )

6) you could add some checking of the Status and Pcon registers to help identifiying the problem ( add a couple of leds i.e. )

Alain

[ardhuru]

Hi,

Besides what Archangel and Acetronics suggest, I'd also suspect the load. Your heating coil draws a lot of current, and I suspect the spurious resets would be happenning when the relay releases.

A snubber circuit accross the load might help.

Or, a solidstate relay that switches at zero crossover?

Regards,

Anand

[Archangel]

Hi,

. . . Your heating coil draws a lot of current, and I suspect the spurious resets would be happening when the relay releases.

A snubber circuit accross the load might help.

Anand
Wow, it did not occur to me it was an electric resistive heater, I was thinking it was gas . . . Good call.

[hbalit]

Thanks to all for sending suggestions to solve my problem.

I do have a commercial opto isolation module in the circuit and this sends a voltage to the remote contactor coil at the heater.

I have added command to my code to display on a LCD so I could follow the program flow and monitor where the problem occurs.

I have now had more fun for the last 11 hours simulating and watching the program do its work with the actual heater disconnected. (more fun than watching paint dry) Ha Ha.
The program did fail twice in that time and it appears that it goes to the temperature read subroutine and then suddenly resets. The point when this happened was when the temperature just got to the minimum trigger setpoint. My LCD display did not indicate that it left the subroutine and went to the comparison section.

I am going to try battery power but I do not suspect that is the problem as I have a 2A 5V supply that is fed off a different circuit than what the heater is on.

I will keep plugging along.

Harold

[Archangel]

Hi Harold,
What kind of lighting is in the area you are working? Sometimes Fluorescent lights make unshielded PICs behave badly.

[Demon]

Hi Harold,
What kind of lighting is in the area you are working? Sometimes Fluorescent lights make unshielded PICs behave badly.

I didn't know that. What kind of shielding? A metal enclosure?

Robert

[Archangel]

Hi Robert,
I scrapped out a TV a Magnavox that had metal shields around it's CPU chips, they fit under and over them, only the pins were not shielded. Some forum members here have reported this problem in the past. I think breadboards would be esp. susceptible . . Remember RF crawls around on the surface whereas DC goes through a conductor.