Anelok: 2014 edition, first results

Werner Almesberger werner at
Mon Jul 28 06:15:46 UTC 2014

I started building the next version of the Anelok board. While my
approach with the first board was to put everything together as
quickly as possible and then see what happens, I'm doing things more
incrementally this time, measuring the system's performance as I go.

This is a view of the partially populated top of the board:

The two MCUs are already there but only the KL26 is currently powered.

I had some fun with its clock circuit, which is now based on a 32.768
kHz crystal. It turns out that 1) the crystal oscillator runs a bit
faster than theory would suggest - not sure if this is "normal" or due
to some mistake I made, and 2) that the FLL (Frequency-Locked Loop)
that generates the (up to) 48 MHz system clock systematically runs 558
ppm slow.

For a Full-Speed USB host, the tolerance is only +/- 500 ppm. But by
deliberately detuning the crystal oscillator and making it run even
faster, I can reduce the error to 330 ppm - good enough.

This means that any RTC based on the 32.768 kHz clock will have to be
corrected by software, but besides this it seems that this clock setup
will work.

A look at the bottom side:

The colorful wires are for Flashing the KL26. They will disappear when
I get around to building a proper test fixture. The battery doesn't do
anything yet - power comes through the clips, where I can measure what
exactly is going on. At the moment, the system draws about 504 uA in
"standby" ... which is roughly 500 uA more than it should draw.

Not sure yet where the leak is. The boost converter had some problems
until I added a pull-down to its enable input. Maybe it get damaged in
the process. I'm also seeing strange voltages (~ 300 mV) on the
CC2543, which should be completely unpowered. More research is
evidently needed.

Speaking of powering the CC2543, I also discovered the first major bug
there: I swapped VSYS (system voltage, the power supply that feeds all
the rest) and VRF (supply of the RF side) at the rfkill switch.

So now "rfkill" still disconnects VRF from VSYS, but then it's not VRF
that gets shorted to ground but VSYS. Aww ...

Well, that's what sharp knives and yellow wires are for :-)

To be continued ...

- Werner

More information about the discussion mailing list