PIC 18 Reset Problem

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?

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

I believe your reasoning is correct.

I had very similar problem with 68HCS12 because of the clock monitor circuit. PIC18 does have the clock monitor also.

Solution:

Check the bit which tells that the micro is running on the internal osc. If it is so, initiate the reset. It is convenient to do all of that in the watchdog reset subroutine.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

It seems like putting a bucket over the _real_ cause of the problem, but it looks like a solid answer if the PIC will cough up that information.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

We are having problems with two lots of PIC18F248 chips (old product) that are reseting randomly 0-10 seconds into startup. If they don't reset in that time they carry on working fine. They are running at 40MHz (HSPLL 10MHz). We have Microchip working on the problem.

If we cool the chips with "Freeze Spray" before powerup they work fine. I was wondering if your problem is fixed the same way? This might give us some clues...

Reply to
Allan Wilson

If oscillator startup delay is the problem then surely the solution is to use a POR circuit with a longer delay before allowing the processor out of reset rather than some sort of software reset loop? Fix rather than mask the problem.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

... snip ..

... snip ...

That actually makes sense, provided that the PIC reassigns that clock input pin to some other use when it doesn't find an active clock. I don't have any real answer.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

DISCLAIMER: I mostly use 16F PICs, but I am somewhat familiar with the

18F's.

Tim Wescott wrote:

Allot of what you are describing could possibly be explained by your _CONFIG word values. The oscillator settings can be quite confusing. I assume that your external clock is really 10MHz and you are using the internal 4x multiplier. There is also the oscillator fail detection/switching and two-speed start-up that could be involved. Are you using the power-up timer?

Reply to
Anthony Fremont

I am using a clock oscillator that puts out 40MHz, and feeding it straight into the PIC. They mention this as being OK in the data sheet.

If you know of an oscillator fail detection/switching, can you tell me where to look in more detail? It seems that this is what is going on, but I haven't found a config bit to turn it off. Any power-up timer stuff is using the default configuration, but I looked at that and it all appears to be counters based off of the main clock.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

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.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

Hi Tim, We had a problem when driving a PIC directly. It was solved by putting a small cap of 47pF in series between the oscillator and the PIC. Admittedly it was a 16Fxxx and the frequency was 3.579MHz, but you never know :) Rocky

Reply to
Rocky

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
 Click to see the full signature
Reply to
Tim Wescott

You could do this on a known faulty one, and see if it cures it ? That will confirm the nature of the problem.

-jg

Reply to
Jim Granville

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
 Click to see the full signature
Reply to
Tim Wescott

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)

formatting link

Reply to
Steve at fivetrees

A good example of where a 'safe default', isn't! :)

-jg

Reply to
Jim Granville

Thanks, I think I'll frame this. ;-)

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.

Reply to
Anthony Fremont

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
 Click to see the full signature
Reply to
CBFalconer

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. ;-)

Reply to
Anthony Fremont

Phew. Thanks ;).

Steve

formatting link

Reply to
Steve at fivetrees

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.

Reply to
Neil

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.