PIC 18 Reset Problem

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.