anelok: more hardware testing
werner at almesberger.net
Sun Oct 13 05:53:06 EDT 2013
I've now placed all the components and tested some more of them.
This is what the complete board looks like:
- wheel: works in general, but the button is sometimes "slow". Not
yet sure what causes this. Could be a cracked trace, a problem in
the component, or a firmware problem, e.g., overly aggressive
- boost converter: works but I noticed that, when disabled, Vout =
Vin. This seems to be a low resistance path, which would mean that
high leakage of anything on the 3.3 V rail could drain the battery.
In this case, a FET to cut off that part or the entire rail would
The 3.3 V rail feeds the display and the memory card. The memory
card already has a FET (but see below). For the OLED, the design
relies on its own power-saving capabilities. Early tests with the
MCU-less board have shown a substantial standby current (114 uA)
into the OLED, well above the 1-3 uA the data sheet specifies. If
further testing confirms this, the FET may be needed.
Nothing to worry about, but needs looking into when analyzing the
standby power consumption.
- speaking of FETs, when the battery is low, the voltage difference
between the MCU's supply and the 3.3 V rail should be large enough
to open the memory card's FET. In other words, it will stop working
as an off switch.
The easiest way to fix this is probably by adding an n-FET and a
pull-up resistor. Again, nothing major.
- OLED: that one gave me a bit of trouble. First, I had a short
beteen two connector pads, causing the system to draw up to 500
mA (which I eventually let it do, to find at least what part was
heating up). That took me a while to find.
Then I had stupidly mislabeled the D/nC signal as CnD and
faithfully copied the inverted logic into the firmware. Suspecting
that the display didn't work because of the previous short, I
replaced it, only to find that it may still have been perfectly
good. Ah well.
The OLED has another surprise: there are tiny little traces left
and right from the pads on the FPC. If there's exposed copper
under that area, it could be shorted to ground. Of course, I have
a trace just there. I solved this by trimming the FPC in the
prototype and by moving the trace out of harm's way in the layout.
The OLED now works. I found that, when hammering it quite a bit,
the content jumps vertically about once every 1000 screen updates
on average. Not sure yet what causes this. Probably a software
- RF: I completed that circuit as well and wrote a driver that can
read the chip version and the RNG. Still have to do actual
over-the-air transmissions and send the clock to the MCU, but I
don't expect surprises there.
The last major components that aree not verified yet are USB and the
memory card. The memory card should be easy (I can reuse the tiny
MMC driver of the Antorcha/Tornado project) but USB will be its usual
Then, power needs a closer look. The things to check there are:
- operation under USB power,
- operating current at 3.0 V (nominal battery voltage),
- operating current at 2.0 V (battery cut-off voltage),
- standby current at 3.0 V,
- standby current at 2.0 V.
This includes putting the MCU into deep sleep (and waking it up
again), and optimizing GPIO settings and such to minimize leakage.
My goal is to have an overall standby current below 10 uA, which
would make the battery last for over two years. It may be possible
to achieve a much lower standby current, in the order of just a
few uA, but we'll see.
Another thing that needs verifying is whether all the signals
needing special functionality (e.g., interrupts, SPI, wakeup) are
indeed on pins with that functionality. Right now, I'm doing
everything with bit-banging and polling.
More information about the discussion