|
|
View previous topic :: View next topic |
Author |
Message |
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
Strange reset behavior. PIC doesn’t start. |
Posted: Wed Jun 10, 2009 3:51 pm |
|
|
Colleagues,
I have a PIC18F4620 that refuses to start when the power is turned off and then re-applied. Vcc has a fair amount of capacitance and the voltage stays between 0.4V and 0.6V for some time. The problem is that if Vcc goes back to +5V, the PIC doesn’t start. If MCLR# is toggled, the PIC starts and operates normally. MCLR# has 47k pull-up.
A bleed resistor could be added between Vcc and ground, but I don’t want to add it because my device is battery powered. I have a brownout detection enabled, but something’s wrong.
Any suggestions or insights would be appreciated.
Code: | #include <18F4620.h>
#device ICD=TRUE
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
// #FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES BROWNOUT
#FUSES BORV43 //Brownout reset at 4.6V (highest brownout threshold)
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected 8from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
setup_oscillator(OSC_8MHZ); |
PIC18F4620, Vcc=+5V, MCLR# has a 47k pull-up
PCWH 4.081
Cheers,
- Nick _________________ Read the label, before opening a can of worms. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jun 10, 2009 3:57 pm |
|
|
Quote: |
I have a PIC18F4620 that refuses to start when the power is turned off
and then re-applied |
Post what you mean by "refuses to start". How far into the program
does it go ? How can you tell ?
Post your main(). Ideally, it should just consist of a LED blinking loop,
for this test. Also, disconnect all external user application circuits except
the LED and its series resistor.
Post if you are running this as a standalone program, or if you are
running it in debug mode.
Is the debugger/programmer plugged into the board ? Which one
are you using ? (ICD-U40, ICD2, etc.) |
|
|
Ttelmah Guest
|
|
Posted: Thu Jun 11, 2009 3:35 am |
|
|
Two other comments.
Use PUT, rather than NOPUT. If the supply rail rises slowly, there can be problems with the oscillator refusing to start. PUT will help in this case.
Consider adding a diode, resistor and small capacitor to the MCLR pin. If you pull the data sheet for the 18F452, and look at the section for 'reset', this shows the circuit you should use (it is illustrated in several other PIC data sheets as well). Basically, what you do, is have a small capacitor (0.01uF say), connected at one end to 0v, and the other end via a resistor to the MCLR pin (use perhaps 150R). This capacitor then has the pull up (perhaps 22KR), and a diode, to discharge it quickly when the power rail falls. This is the recommended reset circuit, if the supply takes more than a few uSec to rise to 5v. It sounds as if you have a lot of capacitance on your supply, and as such you should consider this.
Best Wishes |
|
|
nostep
Joined: 04 Mar 2009 Posts: 16
|
|
Posted: Thu Jun 11, 2009 4:35 am |
|
|
What's connected to your outputs, anything? I've seen external devices hold up the processor from starting properly if they are powered and the power finds its way back to some processor pins. As suggested, the PUT timer should help. |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
|
Posted: Thu Jul 09, 2009 12:48 am |
|
|
Fixed this problem by adding an external reset supervisor MAX809. _________________ Read the label, before opening a can of worms. |
|
|
Guest
|
|
Posted: Sat Jul 11, 2009 7:37 am |
|
|
so basically U R saying
it WAS the lack of hardware management
of the MCLR pin - that was your problem? |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
|
Posted: Sat Jul 11, 2009 11:43 am |
|
|
Anonymous wrote: | so basically U R saying
it WAS the lack of hardware management
of the MCLR pin - that was your problem? |
Back then, I ran out of time and resorted to a "paint over" approach. I didn't do all of the necessary diagnostic steps to find the root cause of the problem. _________________ Read the label, before opening a can of worms. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Sun Jul 12, 2009 2:44 pm |
|
|
Whoa whoa...
If you have ICD=TRUE, I don't think the pic will normally just run (depending on environment settings)
If you don't have the debugger hooked up and then enable the firmware to go.. You shouldn't be programming with ICD=TRUE.
When you want the system to be autonomous, you have to comment out the ICD=TRUE and then recompile and program.
Otherwise, when I use ICD mode, I'm always at the helm anyway.
So maybe this helps?
Cheers,
-Ben
BTW, I'm using a project now with an 18F4620 and it works just fine with ICD=TRUE, PROVIDED I'm ACTUALLY debugging. Otherwise I comment out ICD=TRUE for a more "production" build. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|