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: http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-top-0728.jpg 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: http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-bot-0728.jpg 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 _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
