Ultra low power microcontroller design - LCD Clock

[Howardlong]

10M, yes that was carefully chosen. The problem is that you want the MCU to wake up immediately to a button press, not wait for a half second or so to poll it. Equally, you need it to pull up strongly enough not to cause the input to go into a linear region, or indeed oscillate. But when the button is pressed, you don't want it to take gallons of power when it pulls low, relatively speaking. I spent half a day on various complex schemes to minimise current, including mux scenarios, but this was the least bad. It debounces well too. Sure, if you put your finger on the GPIO pin it'll merrily oscillate at 50Hz.

How about this:
Connect the currently-grounded ends of the buttons to two I/O pins ( PGC/PGD are available, buttons won't affect programming). Set them as low outputs.
Cofigure button inputs for interrupt-on-change, with the internal pullups.
When pressed, the change interrupt flips the corresponding IO pin state and also changes the pullup to pulldown, so no current drawn and MCU can go back to sleep ASAP. The reverse on the next IOC.
The slow clock (assuming you're running at 32K) will probably do enough debounce. 
 Just for good measure, do an occasional poll when awake in case IOC somehow got missed and pullups/IO pins have gone out of phase.

That was precisely one of the methods I tried, although I used other pins, there are quite a few pins left over. There are probably small remnants of it in the source code I attached. I am running at FRC 8MHz... because I found agregate static plus dynamic current draw is actually worse at 32kHz than at 8MHz, which seems to be the sweet spot.

Using the method you mention I found there was relatively high current draw, about 5 to 10uA, when you quickly pressed the buttons, quite a common use case when adjusting the time. However after burning half a day at it and creating an increasingly complex state machine to implement it, I went back to a simple pullup setup which draws 250nA when the button's pressed. I might revisit it, because I never fully understood what was going on and why there was so much current draw, but sometimes you have to draw a line or else I find myself becoming unnecessarily fixated on one small facet.

I did also specifically measure pulling those inputs to a supply rail rather than at the end of a 10M and there was no measurable difference in current draw.

[mikeselectricstuff]

I've driven my clock LCDs as slow as 2hz for those with a second hand.  Since your LCD has the ':' blinking on and off each second, you should be able to get away with a 4hz refresh as long as it is synchronous with the blinking.

At what point do you start causing LCD damage?

Doubt it's an issue as long as long-term avarage is 0

[mikeselectricstuff]

LCD is driven at 16Hz. I started at 32Hz but reduced power fairly significantly dropping to 16Hz. I don't think the peripheral will go any lower, but even at 16Hz this is pretty low. I can't see any visible flicker though.

How much of the draw is down to the LCD  (and LCD controller)?
If the inbuilt LCD module can't go below 16Hz, I wonder if simply bit-bashing slower with IO ports and not using the LCDC might save something.

[Howardlong]

LCD is driven at 16Hz. I started at 32Hz but reduced power fairly significantly dropping to 16Hz. I don't think the peripheral will go any lower, but even at 16Hz this is pretty low. I can't see any visible flicker though.

How much of the draw is down to the LCD  (and LCD controller)?
If the inbuilt LCD module can't go below 16Hz, I wonder if simply bit-bashing slower with IO ports and not using the LCDC might save something.

Bit banging was my first attempt, reason being that the LCD peripheral in the DS showed reasonably high current consumption, but as I mentioned in the vid, I found out later that was in multiplexed mode (i.e., required power-expensive biasing) rather than static mode. At 32Hz bit banging it appeared to be way too expensive, but at that time I didn't realise I could get away with going down to a lower frequency.

I don't have enough experience of direct driving LCDs to be honest, this was my first time doing so, so I don't know what the longer term effects are of lower frequency operation. What I've been trying to avoid is DC on them which I know is a no-no.

[BrianHG]

LCD is driven at 16Hz. I started at 32Hz but reduced power fairly significantly dropping to 16Hz. I don't think the peripheral will go any lower, but even at 16Hz this is pretty low. I can't see any visible flicker though.

How much of the draw is down to the LCD  (and LCD controller)?
If the inbuilt LCD module can't go below 16Hz, I wonder if simply bit-bashing slower with IO ports and not using the LCDC might save something.

Bit banging was my first attempt, reason being that the LCD peripheral in the DS showed reasonably high current consumption, but as I mentioned in the vid, I found out later that was in multiplexed mode (i.e., required power-expensive biasing) rather than static mode. At 32Hz bit banging it appeared to be way too expensive, but at that time I didn't realise I could get away with going down to a lower frequency.

I don't have enough experience of direct driving LCDs to be honest, this was my first time doing so, so I don't know what the longer term effects are of lower frequency operation. What I've been trying to avoid is DC on them which I know is a no-no.

Long term DC is a no-no.
For driving your LCD, just output the digits active high and the common to ground.
4 times a second, just invert the digit IOs and invert the common to high.

For your clock, this means Once a sec, feeding the new set of 7 segments on the clock.
Every sec, and half sec for the ':'.
Inbetween each half sec, invert the value on the segments, ':', and common.

This would be a procedure where the average voltage bias on the entire LCD segs would be 0v meaning it is safe for long time use.


Just to be careful here, we are not using the LCD voltage charge pump, I am assuming your chosen LCD will go black with the voltage difference between GND and your VCCIO.

[edavid]

I've driven my clock LCDs as slow as 2hz for those with a second hand.  Since your LCD has the ':' blinking on and off each second, you should be able to get away with a 4hz refresh as long as it is synchronous with the blinking.

At what point do you start causing LCD damage?

Doubt it's an issue as long as long-term avarage is 0

There must be some minimum drive frequency to avoid the damage that is caused by DC.  Has anyone ever seen a spec on this?

[Howardlong]

Just to be careful here, we are not using the LCD voltage charge pump, I am assuming your chosen LCD will go black with the voltage difference between GND and your VCCIO.

At 2.5 to 3.3V Vdd there's not problem (5 to 6.6Vpp SEG-COM). It works down to 2V but the display loses contrast significantly. To implement a charge pump completely blows the power budget out of the water, it's a design compromise.

[BrianHG]

There must be some minimum drive frequency to avoid the damage that is caused by DC.  Has anyone ever seen a spec on this?

Around a few days for LCDs within the pas 20 years.  Have you ever seen unconnected LCDs with some characters left on due to a static charge at one point, basically a charged DC on voltage.  I've had a few in my box of junk parts, they work fine once connected up.  The key is the shorter, the better.  Anything less than minute, as long as each segment is either off, or, 50% of the time a positive charge, 50% of the time a negative charge, damage wont build up on one side of the conductive traces printed on the LCD glass.  LCD controllers usually operate faster for the multiplexing and if the have a switched cap voltage doubler, the charge pump they cycle at each inversion to make enough electricity to keep the pixels dark.

[David Hess]

Oscillator startup times from cold power up, VDD yellow, 8MHz FRC green, 32.768kHz crystal oscillator blue. Note that I modified the code to output the SOSC on a buffered REFO pin as probing the SOSC low power oscillator crystal directly is extremely difficult to do without stopping the oscillator. Even spring grounded techniques with Tek 3.9pF/10Mohm load passive probes, or 0.6pF/0.3pF single ended/differential 100kohm FET browser probes stopped the oscillator.

Including a JFET source follower as part of the circuit will allow probing the oscillator behavior without disturbing it.

[NiHaoMike]

I once took a LCD from a calculator or something and left it connected to a 9V battery for a few months. I did not see any adverse effects, so either that LCD was unusually robust or the issue takes years to show up.

[edavid]

I once took a LCD from a calculator or something and left it connected to a 9V battery for a few months. I did not see any adverse effects, so either that LCD was unusually robust or the issue takes years to show up.

Yes, it can take years, and I think it's also temperature dependent, which is why I would want to see some kind of spec before assuming there won't be a problem.

[Ian.M]

http://ecee.colorado.edu/~moddel/QEL/Papers/PerlmutterEtAl96.pdf has some info on the degradation mechanism and timescales.   Also there are reports that the InSnO electrodes can be reduced to an opaque In/Sn alloy or eroded away around defects in the alignment layer that expose the electrode to the liquid crystal fluid. 

[Howardlong]

I have an update, I have managed my nirvana, and achieved an average just under 1 uA clock, albeit only 4 digits. You could reduce this further if you don't want a flashing colon.

In addition, I offer a multiplexed low pin count 6 digit option that draws about 2.1uA.

Both use the on chip secondary oscillator with a tuning fork crystal.

Furthermore, of interest to others might be this new device, with a claimed 45nA RTC & digitally compensated 1ppm: https://www.microcrystal.com/en/products/real-time-clock-rtc/rv-3028-c7/

[coppice]

Until maybe 10 years ago there was a very peculiar thing in the MCU market. A lot of products do some kind of measure, analyse and display result job. The measurement and analysis parts are usually quite quick, but you need to display the result for maybe 30 seconds, to give the user plenty of time to read it. So, to keep the overall energy consumption low, the display phase is the key part. Its hard to make a sub microamp LCD controller, but its easy to make one that takes a few 10s of microamps. However, most MCUs from the early 2000s required milliamps to keep the LCD running. The Japanese made some 4 bit MCUs that took this requirement seriously. Among the 8 bit and larger MCUs, only the MSP430 and uPD78 families did a good job, yet it would have been so easy for most MCU makers to provide the functionality to compete with them in some high volume applications.

[Howardlong]

The whole thing about low power is a can of worms, and it's incredibly application specific, and one of those many facets of engineering where you need to look at it as a system, and weigh up the pros and cons. For example, running the core at a faster speed for a shorter period of time is often more efficient than using a low speed oscillator, even one that's already running (as is the case in these examples). Wake up times and low voltage retention regulators are another area which confuses the mix.

I spent a lot of time with a device that showed inconsistent results: it looked like it was behaving well, but it turned out that there were relatively huge current spikes when it was coming out of a low voltage sleep mode, charging up a regulator cap, upsetting the results substantially.

Confected benchmarks are seldom useful on their own.

I agree, it's easy if your power budget is 10s of uA: if only many OEMs would even aim to achieve even that!

[coppice]

The whole thing about low power is a can of worms, and it's incredibly application specific, and one of those many facets of engineering where you need to look at it as a system, and weigh up the pros and cons. For example, running the core at a faster speed for a shorter period of time is often more efficient than using a low speed oscillator, even one that's already running (as is the case in these examples). Wake up times and low voltage retention regulators are another area which confuses the mix.

For a mixed signal application a common pattern is that energy consumption is minimised by turning the analogue stuff (including the ADC) on for the shortest possible time. So, you want the processing that works in parallel with the analogue stuff to run as the highest possible speed. Its all a race to get to sleep as soon as possible.

I spent a lot of time with a device that showed inconsistent results: it looked like it was behaving well, but it turned out that there were relatively huge current spikes when it was coming out of a low voltage sleep mode, charging up a regulator cap, upsetting the results substantially.

Tracking the true energy consumption of bursty applications has been a big problems. I've seen people implement designs they were convinced would have a 10 year life from their battery, only to have products return after a couple of years with dead batteries. Sometimes it was that the crude tools available had not measured the true energy consumption over the huge dynamic range between the processing bursts and the idling in between. Sometimes it was insufficient capacitance across the battery, so the battery was facing the full brunt of the high consumption bursts. Sometimes it was usage patterns that had put the product into high consumption bursts at a far higher rate than the designers thought possible.

Confected benchmarks are seldom useful on their own.

There are now some newer ultra low power benchmarks which are far more representative of typical ULP applications. However, ULP characteristics are so application specific you can never tell what you will get overall until you start roughing out a design.

[Howardlong]

ULP characteristics are so application specific you can never tell what you will get overall until you start roughing out a design.

100%. And it's certain that there won't be enough information on the datasheets & errata. Experience and working empirically is the only way.

In the meantime, I'll drop in my current spreadsheet for PICs.

[bson]

Nice.  At 1µA it should be able to run 20+ years off a 210mAh CR2032!

[coppice]

Nice.  At 1µA it should be able to run 20+ years off a 210mAh CR2032!

If you look at the self leakage and corrosion specs for most CR2032s, you won't consistently get more than 15 years life with no load at all. You need to look at some of the things Tadiran have made for some time, or the new generations of solid electrolyte primary cells to get 20 years operation with any reliability.

[anas]

Dear Sir,

Please suggest me the best available Microcontroller whose current consumption is in microamperes, and which can run on the lithium ion coin battery of 3 volt (I am attaching the link below )that microcontroller should also have a Ram which can record the data on the microcontroller memory all east 20-30 events.

Please suggest me this microcontroller.
Please do reply
I want to run my microcontroller from this battery

https://www.digikey.com/en/products/detail/panasonic-bsg/CR2032/31939


Thanks and regards.

[anas]

Dear Sir,

Please suggest me the best available Microcontroller whose current consumption is in microamperes, and which can run on the lithium ion coin battery of 3 volt (I am attaching the link below )that microcontroller should also have a Ram which can record the data on the microcontroller memory all east 20-30 events.

Please suggest me this microcontroller.
Please do reply
I want to run my microcontroller from this battery

https://www.digikey.com/en/products/detail/panasonic-bsg/CR2032/31939


Thanks and regards.