CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Strange reset behavior. PIC doesn’t start.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kender



Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

Strange reset behavior. PIC doesn’t start.
PostPosted: Wed Jun 10, 2009 3:51 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Jun 10, 2009 3:57 pm     Reply with quote

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







PostPosted: Thu Jun 11, 2009 3:35 am     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Jun 11, 2009 4:35 am     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

PostPosted: Thu Jul 09, 2009 12:48 am     Reply with quote

Fixed this problem by adding an external reset supervisor MAX809.
_________________
Read the label, before opening a can of worms.
Guest








PostPosted: Sat Jul 11, 2009 7:37 am     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

PostPosted: Sat Jul 11, 2009 11:43 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Jul 12, 2009 2:44 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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