Oscillator Switching Works sometimes

[Hans Wedemeyer]

I'm trying to using the PIC16LF6720 with H4 4MHz main Oscillator PLL to 16MHz, and allow the code to switch to TIMER1 Oscillator which has 32768KHz input.

Timer 1 OSC is enabled but it's getting a 32KHz signals from a TCXO All signal voltage levels are very good. Although I'm wasting one pin by enabling the Oscillator, it required for Oscillator Swithcing to be enabled.

Switching to and from SlowSpeed() is activated by the user pressing a switch, or by code calls.

This works for about 98% of the time.

When it fails it always fails going into the Low Frequency clock, never fails going from Low Frequency to High Frequency. !

I can predict when switching has failed because the unit appears to be hung. The "Odd effect" (reproducible 100% of the time) is this:

If the failure to switch to Low Frequency happens and I leave the unit running for several minutes (not determined yet how many but I'm sure it's longer than 10 minutes) the unit starts to function normally at Slow Speed and from that time on so long as I do not power cycle switching back and forth Low to High and High to Low Frequency never fails. !

It's as if the code went out to the weeds and finally found it's way back... !

I've tried longer delays to allow for PLL lock and Oscllator switching as per data sheet, and it does not help.

In slow speed there is only one Interrupt enabled and the ISR sets a global value and that's all. I'm trying to convince myself it's not the single ISR that's eating my lunch at 32KHz because once it works, it works fine. !

Here is a snippet of my code which is just about all that is done in the SpeedSwitching function.

I suspect I missed something and simply can't see what I did wrong!

Best regards
Hans W


int KeySwitch=0; // global
////////////////////////////////////
// the key ISR
#int_EXT3
EXT3_isr()
{
KeySwitch=1; // thats all it does
}
////////////////////////////////////
//
void GoSlowSpeed()
{
int done=0;

disable_interrupts(GLOBAL);
disable_interrupts(INT_RDA);
disable_interrupts(INT_RDA2);
disable_interrupts(INT_TIMER3);
disable_interrupts(INT_TIMER1);
// only interrupt still enabled is #int_EXT3
Setup_Oscillator(OSC_TIMER1);// 32Khz

#use delay(clock=32768)
delay_ms(25); // have tried as much as 250mS

enable_interrupts(GLOBAL);
KeySwitch=0;
do{

// slow stuff done here, "done" can be incremented for other reasons.

if( Keyswitch )
{
done++;
}

}while( !done );



disable_interrupts(GLOBAL);

// switch to H4 Oscillator

#use delay(clock=16000000)
setup_OSCILLATOR(OSC_NORMAL);
delay_ms(16); // have tried as much as 250mS.

enable_interrupts(INT_TIMER3);
enable_interrupts(INT_TIMER1);
enable_interrupts(INT_RDA);
enable_interrupts(INT_RDA2);

enable_interrupts(GLOBAL);
}

[Ttelmah]

I'd start by sticking a scope on T1OSO, and verifying that the 32K oscillator signal is seen here. The hang, sounds like the behaviour you get if you switch to an oscillator that is enabled, but not running...
The 'suspicion', is that the oscillator starts up for some reason latter, and once it is running, the problem disappears.
You don't need any delay after switching the oscillator, the chip should do this for you.

Best Wishes

[Guest]

[Guest]

[Hans Wedemeyer]

I've reduced the code to these three lines.

disable_interrupts(GLOBAL);

output_high(PIN_B7); // scope on this pin show B7 to be High

Setup_Oscillator(OSC_TIMER1);// 32Khz The chip goes ut to the weed patch

output_low(PIN_B7); // and takes several minutes before B7 goes low

enable_interrupts(GLOBAL);

With interrupts disabled I find it hard to imagine what the chip is doing for all those minutes !

Pity the ICD-U40 does not allow debugging at 32KHz. Not being able to step through the code makes it difficult to debug. That's why I'm using the scope and doing simple thigns like setting and clearing pins.

I think I'll post this question on the Microchip help pages...
hansw


From the LST file.

.................... disable_interrupts(GLOBAL);
0C0E4: BCF FF2.6
0C0E6: BCF FF2.7
0C0E8: BTFSC FF2.7
0C0EA: BRA C0E6
.................... output_high(PIN_B7);
0C0EC: BSF F8A.7
.................... Setup_Oscillator(OSC_TIMER1);// 32KHz as system clock current goes down to 4.5mA
0C0EE: MOVLW 01
0C0F0: MOVWF FD3
.................... output_low(PIN_B7);
0C0F2: BCF F8A.7
.................... enable_interrupts(GLOBAL);
0C0F4: MOVLW C0
0C0F6: IORWF FF2,F

[PCM programmer]

In your code, you're using Pin B7, but that pin is used by the CCS-ICD.
Are you attempting to toggle that pin, while using the debugger ?
If so, that could explain the problem.

If that's not the problem, then:

1. Can you put the code that you posted above into a small, compileable
test program, that shows the #fuses line, and post it ?

2. Can you post your compiler version ?

[Hans Wedemeyer]

[Ttelmah]

I understood that you were using an external oscillator (this is presumably a 'crystal oscillator'...). The point I was making was to look at T1OSO, not the input. In the past, there have been problems on some occasions with the primary oscillator, where if the input is overdriven, it does not run as expected. My suspicion isthat something similar is happening here, and that perhaps the internal gate is getting into an unexpected state, from being driven possibly too hard. If so, I'd expect the output pin, to not be matching the invert of the input signal. This is what I was suggesting testing. The internal 'oscillator', when enabled, has significant gain, and an input that is expecting to receive a noticeably attenuated signal from the output of a crystal, not a 'rail to rail' logic signal.

Best Wishes

[Hans Wedemeyer]

[Ttelmah]

OK. I wondered if you were misunderstanding what I was asking/saying (very easy to do - I do it all the time...).
The only thing I note, is that you are using the 'LF' chip variant. Now this has a different oscillator selected for Timer1 (the 'low power' version of the standard oscillator). You are presumably using the 18LF6720 (you originally say the 16LF6720)?.
I have only used switching like this on the standard (not low power) variant, and had no problems.
The only erratum for the 6720, should not affect this.
I am interested that you see the output change when the oscillator switch takes place. I would not have expected this (the oscillator is 'stand alone', and only it's output connects into the system clock multiplexer). Interesting!...
My actual thinking about problems, was in two specific situations. The first was what happens if your external clock starts before 'MCLR' rises?. The second was what happens if it starts before Vdd rises?. Though the normal PIC inputs are fairly well protected against the old CMOS latchup behaviour, I fond myself wondering if this was true for this low-power gate?...
If the external oscillaor has an 'enable', could you connect it to the PICs MCLR, to disable the oscillator till the PIC starts?.

Best Wishes

[Hans Wedemeyer]

A 10K pull-up on the TCXO/T1OSI pin and I have still not been able to make it fail. !

I hate these bump in the night fixes.

Without knowing what the output stage really is in the DS32KHz, or what the PIC T1 Oscillator stage looks like, there no way of knowing why it fixed the problem.
I have to assume if the extra 10K fixes the problem on other units as well then I'll add it to the list of quirks for the PIC18LF6720 or DS32KHz...

BTW Just for the record. I arranged for the DS32KHz to power up after the PIC, that did not fix the problem.
As it is the DS32KHz and PIC power up on the same VDD, so it was a good suggestion because the DS32KHz outputs a few millisecond before the PIC is ready.

I'm happy it was not a code issue! As I said how many mistakes can I make in one line of code

[Hans Wedemeyer]

Worked fine on a second unit. Third unit wil be modified tomorrow.

Only thing to do now is test the fix at 85C and -40C !

hansw