anelok: more hardware testing

Werner Almesberger 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:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd0-fnt.jpg

Details:

- 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
  clock gating.)

- 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
  be needed.

  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
  problem.

- 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
pain.

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.

- Werner



More information about the discussion mailing list


interactive