I'm using 12F683 / 16(L)F18313 PICs with WDT enabled and they're all exhibiting the same problem. I'm trying to use solar cells as the power source - they all work as expected and without problem using a fixed supply. When the output falls from the solar cell and Vdd drops to just under the minimum operating level (maybe around 1.4v) the PIC stops - I've got a bit of code that detects WDT and signals it happened by pulsing an output. If the WDT is detected and the voltage rises again then the PIC operation restarts ... but sometimes, rarely, it doesn't and sometimes the WDT is not detected either. Under this circumstance, the only way of recovery is to short out the power rail - there's a 100 mfd across the supply and it can hold its charge for quite a while.
Is it possible for a PIC to simply lock-up due to restarting in an indeterminate state ? I did wonder about using an LDO regulator - the data sheets don't say what happens with devices like MCP1700 when the input volts drop under the minimum ... it'd be good if the output dropped to zero. Another thought I had was to use voltage level detection to hold MCLR low until above a threshold.
I'd suppose that this type of problem might manifest itself whenever power is applied and maybe, I'm hoping, there's a recommended solution ?
Thanks,
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought about that but I do think that the chip is actually doing what some called being "bricked" ! As the WDT seems to not be working then not much else is likely to be working either.
Just provoked this problem again and the PIC froze with one of its outputs permanently high :
GPIO.5 = 1
Wait 5mS <===-- It must've frozen at this point.
GPIO.5 = 0
Might it be the on chip oscillator that dies first ?
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just some suggestions:
Always use a 0.1uf cap across supply with micro
Try to inline code, no interrupts or subs?
Use the WDT , along with sleep, for wait
Initialize all variables?
There are other ways to check for restart, like the STATUS register
Charge a battery with the solar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Kent - it does seem to be associated with an interrupt ... I still think that the chip freezes due to something getting corrupted by the failing voltage level. I use a couple of Sleep statements so the WDT does not reset the PIC (no option for 12F683) ... so forced it by Goto 0 after the Sleep instructions ... since then it's not hung ! Still think that the answer's going to be holding MCLR down by some form of voltage threshold detection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you got it working!
Some WDT's allow reset I believe or program continuation.
Other thoughts or considerations:
Highly recommend 10k pullup on MCLR pin per data sheet (so POR circuit works correctly)
Use clrwdt instruction instead of sleep as needed
Use clrwdt before sleep per data sheet
Use nop directly after sleep if using interrupts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The data sheet gives the peripherals that can generate an interrupt during sleep (INT pin, GPIO change, etc.). The next instruction after sleep will be executed prior to branching to the interrupt address. So, it all depends if that instruction is detrimental or not.
As a general rule, I always use a nop after sleep, and then I don't worry about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.4V is way below the min VDD spec for any of those devices, so all bets are off.
Heck, it's even below the ram retention voltage!
12F683 VDD min = 2V
16F18313 VDD min = 2.3V
16LF18313 VDD min = 1.8V
You should enable the brown out reset (BOR), which is different for each of those devices:
12F683 VBOR = 2.0V
16F18313 VBOR = 2.45V or 2.7V (selected with config BORV)
16LF18313 VBOR = 1.9V or 2.7V (selected with config BORV)
The LF18313 has a LPBOR to extend it even lower.
Using an LDO isn't going to help any. When the input voltage falls below the LDO;s rated output voltage then it pretty much just tracks the input (minus the dropout voltage), at least until you get to the LDO's min input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the input Jerry ! At the moment it's much more stable and I removed a Sleep that was within an interrupt - it too was provoking a couple of weird hangs. I'm just to trying to get a handle on how the PIC recovers from working "in the twilight zone" of 1.4v (which oddly my PICs do quite well) ... but any lower and I've found that the PIC locks completely - it does nothing and looks dead until Vdd is shorted to Gnd. What I want to achieve is an automatic recovery when the sun comes out ! This situation can't be that unique - batteries go flat too but maybe not as frequently as it going dark.
I've not used brown out reset before but enabling the BOR peripheral comes with a relatively high increase in power demand and I suspect that it too might suffer the same fate as the rest of the PIC as it tries to recover.
I'd thought that an LDO with a voltage healthy flag could be used to hold the PIC in a permanent reset state and Microchip have low voltage detector TC54 that might also prove useful.
To reiterate, I need to devise a solar powered PIC module that runs, without any intervention, when the light permits with nigh on 100% reliability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may need a Microchip Voltage Manager device on your reset pin. It will hold the device in a reset state down to 1.2 volts but, as Jerry said, you need greater than 1.4 volts to avoid going into reset. The monitor chip only prevents premature wake up.
Could you try using two solar cells in series , if it is solar powered, to increase the voltage, and maybe a super cap as a reservoir?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've not used brown out reset before but enabling the BOR peripheral comes with a relatively high increase in power demand and I suspect that it too might suffer the same fate as the rest of the PIC as it tries to recover.
Yeah, you have to balance it's Ipd against using some external circuitry.
I haven't used this part, but the LF18313 has a low-power BOR (LPBOR, sect 6.3) that only uses 2uA or so and if I'm reading the datasheet correctly appears to work down to about 0.8V (spec D005, Vporr)
It might be worth playing around with... in general the BOR works pretty well with other parts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Thanks everyone - I've found that no matter how the PIC is configured or what features are enabled, I can always "lock" the PIC eventually and the only recovery method is to short out Vdd or use MCLR. I've now tested the TC54 2.7v voltage detector connected to MCLR and it is now "rock solid" and I can no longer provoke the problem. Practically the TC54 is a nuisance to breadboard because it is surface mount. 2.7v is a bit high, so I'm going to trial the MCP111 1.9 v / 2.32v detectors and they have a TO92 package option.
So that's my solution ... for now !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using 12F683 / 16(L)F18313 PICs with WDT enabled and they're all exhibiting the same problem. I'm trying to use solar cells as the power source - they all work as expected and without problem using a fixed supply. When the output falls from the solar cell and Vdd drops to just under the minimum operating level (maybe around 1.4v) the PIC stops - I've got a bit of code that detects WDT and signals it happened by pulsing an output. If the WDT is detected and the voltage rises again then the PIC operation restarts ... but sometimes, rarely, it doesn't and sometimes the WDT is not detected either. Under this circumstance, the only way of recovery is to short out the power rail - there's a 100 mfd across the supply and it can hold its charge for quite a while.
Is it possible for a PIC to simply lock-up due to restarting in an indeterminate state ? I did wonder about using an LDO regulator - the data sheets don't say what happens with devices like MCP1700 when the input volts drop under the minimum ... it'd be good if the output dropped to zero. Another thought I had was to use voltage level detection to hold MCLR low until above a threshold.
I'd suppose that this type of problem might manifest itself whenever power is applied and maybe, I'm hoping, there's a recommended solution ?
Thanks,
Andrew
Would a brown-out reset work better (never tried it so I don't know).
I thought about that but I do think that the chip is actually doing what some called being "bricked" ! As the WDT seems to not be working then not much else is likely to be working either.
Just provoked this problem again and the PIC froze with one of its outputs permanently high :
GPIO.5 = 1
Wait 5mS <===-- It must've frozen at this point.
GPIO.5 = 0
Might it be the on chip oscillator that dies first ?
Andrew
Just some suggestions:
Always use a 0.1uf cap across supply with micro
Try to inline code, no interrupts or subs?
Use the WDT , along with sleep, for wait
Initialize all variables?
There are other ways to check for restart, like the STATUS register
Charge a battery with the solar
Thanks Kent - it does seem to be associated with an interrupt ... I still think that the chip freezes due to something getting corrupted by the failing voltage level. I use a couple of Sleep statements so the WDT does not reset the PIC (no option for 12F683) ... so forced it by Goto 0 after the Sleep instructions ... since then it's not hung ! Still think that the answer's going to be holding MCLR down by some form of voltage threshold detection.
Glad you got it working!
Some WDT's allow reset I believe or program continuation.
Other thoughts or considerations:
Highly recommend 10k pullup on MCLR pin per data sheet (so POR circuit works correctly)
Use clrwdt instruction instead of sleep as needed
Use clrwdt before sleep per data sheet
Use nop directly after sleep if using interrupts?
"Use nop directly after sleep if using interrupts?"
I've seen this reference before - can you enlighten me as the reason ?
The data sheet gives the peripherals that can generate an interrupt during sleep (INT pin, GPIO change, etc.). The next instruction after sleep will be executed prior to branching to the interrupt address. So, it all depends if that instruction is detrimental or not.
As a general rule, I always use a nop after sleep, and then I don't worry about it.
1.4V is way below the min VDD spec for any of those devices, so all bets are off.
Heck, it's even below the ram retention voltage!
12F683 VDD min = 2V
16F18313 VDD min = 2.3V
16LF18313 VDD min = 1.8V
You should enable the brown out reset (BOR), which is different for each of those devices:
12F683 VBOR = 2.0V
16F18313 VBOR = 2.45V or 2.7V (selected with config BORV)
16LF18313 VBOR = 1.9V or 2.7V (selected with config BORV)
The LF18313 has a LPBOR to extend it even lower.
Using an LDO isn't going to help any. When the input voltage falls below the LDO;s rated output voltage then it pretty much just tracks the input (minus the dropout voltage), at least until you get to the LDO's min input.
Thanks for the input Jerry ! At the moment it's much more stable and I removed a Sleep that was within an interrupt - it too was provoking a couple of weird hangs. I'm just to trying to get a handle on how the PIC recovers from working "in the twilight zone" of 1.4v (which oddly my PICs do quite well) ... but any lower and I've found that the PIC locks completely - it does nothing and looks dead until Vdd is shorted to Gnd. What I want to achieve is an automatic recovery when the sun comes out ! This situation can't be that unique - batteries go flat too but maybe not as frequently as it going dark.
I've not used brown out reset before but enabling the BOR peripheral comes with a relatively high increase in power demand and I suspect that it too might suffer the same fate as the rest of the PIC as it tries to recover.
I'd thought that an LDO with a voltage healthy flag could be used to hold the PIC in a permanent reset state and Microchip have low voltage detector TC54 that might also prove useful.
To reiterate, I need to devise a solar powered PIC module that runs, without any intervention, when the light permits with nigh on 100% reliability.
You may need a Microchip Voltage Manager device on your reset pin. It will hold the device in a reset state down to 1.2 volts but, as Jerry said, you need greater than 1.4 volts to avoid going into reset. The monitor chip only prevents premature wake up.
Could you try using two solar cells in series , if it is solar powered, to increase the voltage, and maybe a super cap as a reservoir?
Yeah, you have to balance it's Ipd against using some external circuitry.
I haven't used this part, but the LF18313 has a low-power BOR (LPBOR, sect 6.3) that only uses 2uA or so and if I'm reading the datasheet correctly appears to work down to about 0.8V (spec D005, Vporr)
It might be worth playing around with... in general the BOR works pretty well with other parts.
Hi, Thanks everyone - I've found that no matter how the PIC is configured or what features are enabled, I can always "lock" the PIC eventually and the only recovery method is to short out Vdd or use MCLR. I've now tested the TC54 2.7v voltage detector connected to MCLR and it is now "rock solid" and I can no longer provoke the problem. Practically the TC54 is a nuisance to breadboard because it is surface mount. 2.7v is a bit high, so I'm going to trial the MCP111 1.9 v / 2.32v detectors and they have a TO92 package option.
So that's my solution ... for now !