MC1321x FLL continuously looses lock when using high frequency range

[MarcB]

I'm trying to increase the clock output of the modem in the MC1321x so that I can use it as clock input for another external MCU. The original setting from the Beekit myWirelessApplication sample code is:

- #define CLOCK_OUT_SETTING   0x7E85 (nv_data.h), which outputs 62.5 KHz out of the modem
- NV_ICGC1 = 0x18 (nv_data.c), which sets the oscillator as low frequency range (FLL loop prescale factor P is 64)
- NV_ICGC2 = 0x20 (nv_data.c), which sets the multiplication factor to 8

So the MCU will run at 62.5 KHz * 64 * 8 = 32 MHz, which is what we want


Now I would like to output 8 MHz from the modem instead. I've changed the above settings to:

- #define CLOCK_OUT_SETTING   0x7E81 (nv_data.h), which outputs 8 MHz out of the modem
- NV_ICGC1 = 0x58 (nv_data.c), which sets the oscillator as high frequency range (FLL loop prescale factor P is 1)
- NV_ICGC2 = 0x00 (nv_data.c), which sets the multiplication factor to 4

So the MCU will run at 8 MHz * 1 * 4 = 32 MHz

The FLL locks correctly and the hiwave debugger confirms a bus frequency of 16 028 535 Hz, but the loss of FLL lock interrupt gets called continuously thereafter (FLL_Lost_Lock_ISR).

I've tried multiple combinations of modem clock out settings and FLL settings. In summary:
    - If I keep the output in the low frequency range (62.5KHz or 32.786KHz with RANGE bit of ICGC1 = 0), everything works fine (no loss of lock)
    - If I put the output in the high frequency range (2 MHz, 4 MHz pr 8 MHz with RANGE bit of ICGC1 = 1), the problem occurs.

Can anyone give me some pointers on this issue?
Thanks!
Marc

[UK_CF_FAE]

Hi Marc,

Can you pls try it with OSCSTEN set in ICGC1, and let us have some feedback? The comparison cycle is very different between the test with RANGE=0 and RANGE=1, and I'm guessing that, since the part locks once, it will be a low power mode issue.

NV_ICGC1 = 0x5C;

Good luck,

Mark

Message Edited by UK_CF_FAE on 2008-06-17 08:14 PM

[MarcB]

Thanks for the input Mark.

Unfortunately this has not solved the problem.

Is such a clock configuration something that should work? That is supported? That has been tried on one of the dev boards?

Thanks
Marc