i.MX27 External oscillator vs crystal

[craighillis]

When we switched from using a 26MHz crystal to a 26MHz external oscillator, the i.MX27 does not reliably go into sleep mode.

Is there some register setting that needs to be changed to operate correctly with an external oscillator?

[craighillis]

Is there a IRQ or FIQ for a clock instability problem? If so, could this be generating an interrupt preventing the wait for interrupt from allowing the ARM to go to sleep mode?

[Yuri]

Hello,

is it possible to look at codes (to enter sleep mode) ?

Regards,

Yuri.

[craighillis]

Yuri,

We use the same code for both crystal and oscillator:

When using the oscillator, after running the 26MHz Oscillator Trim routine from the reference manual, the values for OSC26M_AGC[5:0] are all 0 and the OSC26M_PEAK[1:0] says we need to trim lower. We can trim properly using a crystal. Not sure if this is the problem. If so, what should the oscillator output be? It is the same 2.8 volts as the VCC_OSC26 supply.

Written in
C using the IAR Embedded Workbench

do

{   
CSCR_bit.SD_CNT = 3;
CSCR_bit.MPEN = 0;
CP15_WFI();

} while(
(rtc_get_time() < end_time) && !das_state_cycle());

CP15_WFI():
register volatile unsigned int temp;
__MCR(15, 0, temp, 7, 0, 4);

Craig

[Yuri]

Hello,

One of sleep mode conditions - disable AHB peripherals from bus accesses.

Is it so ?

Also, if possible let me look at the scheme. please create request to

transfer the scheme.

How to submit a new question for NXP Support

Regards,

Yuri.

[craighillis]

Yuri,

We are running the same code that works with a crystal. We simply remove the crystal and replace it with an oscillator and everything seems to work except properly going to sleep. We suspect that the MPLL is not turning off.

When we change the code to use the 32kHz input for the main clock just before going to sleep, the MPLL shuts off and we go to sleep properly.

We could make this change to use the oscillator, but I am concerned that there is some other hidden problem with the 26MHz source when using the oscillator that could affect other functions.

do

{

CSCR_bit.SD_CNT = 3;

CSCR_bit.MPEN = 0;

CP15_WFI();

} while( (rtc_get_time() < end_time) && !das_state_cycle());

CP15_WFI():

register volatile unsigned int temp;

__MCR(15, 0, temp, 7, 0, 4);

Craig

[Yuri]

Hello,

is it possible to look at oscillator waveforms ?

Regards,

Yuri.

[craighillis]

Yuri,

Attached are oscillator waveforms from the function generator (tek00001.png a sine wave) and from the CSAC (Chip Scale Atomic Clock) board (tek00002.png a square wave). The CSAC board uses a PLL to multiply the 10MHz to 26MHz.

Craig

[Yuri]

Hello,

1.

  The waveforms look correctly.

2.

  Sometimes improper power up sequence can provide unexpected issues.

Please double check power - up.

Regards,

Yuri.

[craighillis]

Yuri,

I have ensured that the signal from the external oscillator is not applied until the power for the 26MHz oscillator in the i.MX27 is up and stable. The problem with shutting down the MPLL still exists.

Further investigation has revealed the following:

If the MPLL has been running and stable, going to sleep works.

In our application, in sleep mode we get a 1 pulse per second (1 PPS) that wakes up the ARM. The ARM checks its schedule. If there is nothing to do it goes back to sleep. This happens very fast. Detailed power measurements have shown that after running for a period of time, when we first go to sleep, the MPLL shuts off. When we get the first 1 PPS, the MPLL does not shutoff when we go back to sleep.

We tried monitoring the LOCK bit for MPLL and waiting for it to be set before going to sleep. The results were intermittent, sometimes it would shut the MPLL down other times it would not. Once it failed to shut down the MPLL, subsequent 1 PPS wake sleep cycles would not shut down the MPLL.

We also put a delay of 100ms before going back to sleep. In this case the MPLL always shut down. Reducing the delay to 400us also resulted in the MPLL always shutting down.

We have not observed this problem when using a crystal, only an external oscillator.

What could be causing a requirement for a delay with the external oscillator?

Could our timing be marginal with a crystal?

Craig Hillis

[Yuri]

Hello,

  Perhaps the problem concers with the fact, that PLL Phase Lock Time is  100 μs,

therefore some pause between wake up and sleep events is needed.

Regards,

Yuri.

[craighillis]

Yuri,

We tried monitoring the lock bit and not going to sleep until the lock bit indicated the PLL was locked. The MPLL still would not shut down when the lock bit was set. We had to add additional time.

Craig

[Yuri]

Hello,

From internal Community - looks like - the using approach

of switching MPPL source to 32 KHz helps.

Regards,

Yuri.

[craighillis]

Yuri,

Thanks for your help.

I will look into the start-up.

Other than not being able to go to sleep properly, could there be some other problem with the 26MHz when using the oscillator? We really need the increased accuracy of the atomic clock oscillator.

Regards,

Craig

[craighillis]

What else could be preventing it from properly entering sleep mode? All other functions seam to be functioning correctly.

One of the conditions for sleep is:

          Clock Controller module has successfully mastered the system bus.

Could something be preventing this from happening? If so what?

[Yuri]

Hello,

  As for use oscillator (instead of crystal) for the 32 kHz input :

Square-wave signal may be applied to EXTAL32K (directly) and

should not exceed OSC32VDD voltage. For 26 MHz : EXTAL26M pin,

and OSC26VDD supply.
Note : for any 26MHz configuration (crystal or generator) OSC26M_DIS

should be cleared.

Have a great day,
Yuri

----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------