EmbeddedRelated.com
Forums

PIC 18 Reset Problem

Started by Tim Wescott August 1, 2007
Tim Wescott wrote:
> I have an odd little problem, I'm hoping one of you could shed some > light on it before I spend hours tracking it down. > > I'm working on a board with a PIC18F8722. We're setting it up to work > in external clock mode with a 40MHz clock. This clock is, in turn, > sourced by an integrated oscillator module from ECS (ECS-8FM). > > The problem that we're seeing is that sometimes the thing comes up going > very slowly. I haven't measured timing yet, but it appears to be > running about 5x or 10x slower than it should. The problem is somehow > related to the power source, with faster rise times on the power supply > inducing it much more often. The only lead that I have on it right now > is that with a sharp-rising power supply the oscillator takes several > milliseconds to start up. > > I'm wondering if the PIC 18 senses that the clock isn't present coming > out of reset and defaults to an internal clock. This seems screwy, but > it makes a twisted kind of sense. IIRC the oscillator is billed as > working at 3.3V, so with a slowly-rising VCC it would presumably > (possibly?) start working before the processor came out of reset. > > Has anyone seen anything like this before, or am I on my own? >
Thank you all, particularly Anthony and Vladimir: There is, indeed a configuration bit to activate a clock fail feature; when active the clock source will switch over to the internal clock with all accompanying problems. The tool that I am using leaves that bit set by default; I have disabled it, and my problem has gone away. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
Tim Wescott wrote:
> Ultimately, yes. The PIC18 is supposed to have its own internal POR > circuit, so I'd have to add parts to the board. If I can fix it cleanly > in software I will.
You could do this on a known faulty one, and see if it cures it ? That will confirm the nature of the problem. -jg
Jim Granville wrote:
> Tim Wescott wrote: >> Ultimately, yes. The PIC18 is supposed to have its own internal POR >> circuit, so I'd have to add parts to the board. If I can fix it cleanly >> in software I will. > > You could do this on a known faulty one, and see if it cures it ? > That will confirm the nature of the problem.
As of yesterday I was able to reliably reproduce the problem while looking at the power supply line and the oscillator -- the oscillator always takes a while to start up, and the problem only happens when the power supply starts quickly. There's a config bit that tells the processor to watch for a clock failure and switch over to the internal clock; I disabled that and all is fine now, under all circumstances. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:o9OdnYy975Oqqy_bnZ2dnUVZ_vLinZ2d@web-ster.com...
> Jim Granville wrote: >> Tim Wescott wrote: >>> Ultimately, yes. The PIC18 is supposed to have its own internal POR >>> circuit, so I'd have to add parts to the board. If I can fix it >>> cleanly >>> in software I will. >> >> You could do this on a known faulty one, and see if it cures it ? >> That will confirm the nature of the problem. > > As of yesterday I was able to reliably reproduce the problem while > looking at the power supply line and the oscillator -- the oscillator > always takes a while to start up, and the problem only happens when > the power supply starts quickly. > > There's a config bit that tells the processor to watch for a clock > failure and switch over to the internal clock; I disabled that and all > is fine now, under all circumstances.
Good to hear. There is one thing there that worries me with that, though. If the clock starts up slowly, and the POR time is counted in clock cycles, no problem. If it's counted some other way (RC? nah, surely not), has the CPU run enough clock cycles during reset to be in a reliably reset state? Steve (probably worrying unnecessarily) http://www.fivetrees.com
Tim Wescott wrote:
> Jim Granville wrote: > >> Tim Wescott wrote: >> >>> Ultimately, yes. The PIC18 is supposed to have its own internal POR >>> circuit, so I'd have to add parts to the board. If I can fix it cleanly >>> in software I will. >> >> >> You could do this on a known faulty one, and see if it cures it ? >> That will confirm the nature of the problem. > > > As of yesterday I was able to reliably reproduce the problem while > looking at the power supply line and the oscillator -- the oscillator > always takes a while to start up, and the problem only happens when the > power supply starts quickly. > > There's a config bit that tells the processor to watch for a clock > failure and switch over to the internal clock; I disabled that and all > is fine now, under all circumstances.
A good example of where a 'safe default', isn't! :) -jg
Tim Wescott wrote:

> Thank you all, particularly Anthony and Vladimir:
Thanks, I think I'll frame this. ;-)
> There is, indeed a configuration bit to activate a clock fail feature; > when active the clock source will switch over to the internal clock > with all accompanying problems. The tool that I am using leaves that > bit set by default; I have disabled it, and my problem has gone away.
Yes, it seems that they have made the oscillator stuff quite confusing by trying to make it all things for all people. Trying to determine how long after power-on or wake-up it takes before instructions start to execute has gotten allot trickier.
Anthony Fremont wrote:
> Tim Wescott wrote: > >> Thank you all, particularly Anthony and Vladimir: > > Thanks, I think I'll frame this. ;-) > >> There is, indeed a configuration bit to activate a clock fail >> feature; when active the clock source will switch over to the >> internal clock with all accompanying problems. The tool that I >> am using leaves that bit set by default; I have disabled it, >> and my problem has gone away. > > Yes, it seems that they have made the oscillator stuff quite > confusing by trying to make it all things for all people. > Trying to determine how long after power-on or wake-up it takes > before instructions start to execute has gotten allot trickier.
I am speaking from ignorance, but it shouldn't need to be confusing IMO. Just let the chip examine the clock input at power on. If there are less than N transitions in T seconds, assume no clock and switch to something internal. There will be a fairly large tolerance to the values of N and T, because they are probably set by some sort of RC time constant. -- "Vista is finally secure from hacking. No one is going to 'hack' the product activation and try and steal the o/s. Anyone smart enough to do so is also smart enough not to want to bother." -- Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
> Anthony Fremont wrote: >> Tim Wescott wrote: >> >>> Thank you all, particularly Anthony and Vladimir: >> >> Thanks, I think I'll frame this. ;-) >> >>> There is, indeed a configuration bit to activate a clock fail >>> feature; when active the clock source will switch over to the >>> internal clock with all accompanying problems. The tool that I >>> am using leaves that bit set by default; I have disabled it, >>> and my problem has gone away. >> >> Yes, it seems that they have made the oscillator stuff quite >> confusing by trying to make it all things for all people. >> Trying to determine how long after power-on or wake-up it takes >> before instructions start to execute has gotten allot trickier. > > I am speaking from ignorance, but it shouldn't need to be confusing > IMO. Just let the chip examine the clock input at power on. If > there are less than N transitions in T seconds, assume no clock and > switch to something internal. There will be a fairly large > tolerance to the values of N and T, because they are probably set > by some sort of RC time constant.
That's pretty much how the clock fail-safe part works. Tim's external oscillator module wasn't starting fast enough to suit the PIC, unless he ramped the power up a bit more slowly. Presumably, the external oscillator will start at a lower voltage; by slowing down the PS ramp up, the PIC would get a late enough start that it would accept the external clock as valid, even though it was probably still out of spec (voltage wise). PICs get a hard rap, but they tend to work pretty much as documented. The confusion comes in when you lump in all the other options. What with the myriad of possible external clocks (RC, XTAL, canned, ....) and the amazing INTOSC module that runs from 31kHz to 8MHz; not to mention the possible 32kHz oscillator clocking TMR1. This is further complicated by the two speed start up facility that allows the PIC to wake up and start executing instructions quickly using a fast starting clock source and then switch to another (more stable) oscillator that starts more slowly. The icing on the cake is that the software can switch between the clock sources......or not (depending upon some CONFIG bits). Your statement tends to beg the question of how does the chip detect no clock when it needs a clock to mark time? The answer lies in the internal RC oscillator that clocks the watch-dog timer and also does the power-up timer. Hopefully Steve at fivetrees won't lose too much sleep worrying about it. ;-)
"Anthony Fremont" <anyone@nospam.com> wrote in message 
news:13b7cro62es3ne2@news.supernews.com...
> > Your statement tends to beg the question of how does the chip detect > no clock when it needs a clock to mark time? The answer lies in the > internal RC oscillator that clocks the watch-dog timer and also does > the power-up timer. Hopefully Steve at fivetrees won't lose too much > sleep worrying about it. ;-)
Phew. Thanks ;). Steve http://www.fivetrees.com
Jim Granville wrote:
> Tim Wescott wrote: >> Jim Granville wrote: >> >>> Tim Wescott wrote: >>> >>>> Ultimately, yes. The PIC18 is supposed to have its own internal POR >>>> circuit, so I'd have to add parts to the board. If I can fix it >>>> cleanly >>>> in software I will. >>> >>> >>> You could do this on a known faulty one, and see if it cures it ? >>> That will confirm the nature of the problem. >> >> >> As of yesterday I was able to reliably reproduce the problem while >> looking at the power supply line and the oscillator -- the oscillator >> always takes a while to start up, and the problem only happens when >> the power supply starts quickly. >> >> There's a config bit that tells the processor to watch for a clock >> failure and switch over to the internal clock; I disabled that and all >> is fine now, under all circumstances. > > A good example of where a 'safe default', isn't! :) > > -jg > >
Not really the CPU is running. It could wait and decide to switch oscillators or Set the system to a "Safe" state. Anyway it is set during programing.