The original design had only one crystal, on the RF chip. The RF chip
would then generate a clock signal for the SoC. The Soc needs a
precise clock for two purposes:
- for USB, and
- for timekeeping.
Since it would be wasteful to run the RF chip all the time just to
provide the clock (*), the idea was to calibrate the low-power RC
oscillator in the KL26 with it, and then keep time based on that,
with occasional wakeup and recalibration.
(*) The AT86RF232 draws about 330 uA when idle. The CC2543 draws
about 3.1 mA in the lowest power mode in which the 32 MHz crystal
If we want to have a "hard" rfkill switch that shorts the RF SoC's
power supply to ground, the KL26 also has to be able to run without
the RF SoC. It therefore needs a local crystal.
The KL26 offers two choices: a high-frequency crystal that draws
between 200 uA and 4 mA just for the oscillator, depending on speed
and configuration, or a low-frequency crystal (32.768 kHz) that can
work with as little as 0.5 uA (25 uA in high gain mode).
0.5 uA is interesting. This is low enough that the crystal oscillator
could run continuously, providing very accurate timekeeping.
Since I have a few small 32.768 kHz crystals lying around, I tought
I'd give it a try in the next board version.
Alas, one can't have more than on such clock source. So if we use a
32.768 kHz crystal, there can be no external clock input.
This means that have to generate also the USB clock from 32.768 kHz.
Unfortunately, the PLL can't do that. But there is a
"Frequency-Locked Loop" (FLL) that can - with the one gotcha that
Freescale state that
"The MCGFLLCLK does not meet the USB jitter specifications for
But it's clearly designed to do just that, and people seem to be
using it in this way.
So let's see how it behaves.
Qi Hardware Discussion List
Mail to list (members only): firstname.lastname@example.org
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion