Low Power Pin Toggling

I am working on an Arduino based watch using an Atmega328p, a sharp memory display (LS013B4DN04) and a ds3231 real time clock. To save power the Atmega gets woken up by the rtc interrupt once per minute to refresh the display. The overall power consumption in Standby (display and rtc on) is under 10uA which lets the watch run for months off of a coin cell.

The problem is that after a few days of use the screen started to show burn-in. But the display was not permanently damaged, the pixels went normal again a few minutes after removing the battery.
According to the datasheet sharp memory displays need a "periodic polarity inversion" that prevents the memory cells from building up charge. This is either done with a bit in a SPI command or a hardware pin on the display. Right now the Adafruit library does this automatically but the signal needs to be toggled once per second even when the Atmega is in standby. It would be a waste to wake the Atmega using over 6 mA every second just to toggle a pin.
I thought about using a 555 timer but even the low power ones those still draw more current than the entire device in standby.
What would be the most efficient way to toggle a pin once per second without using more than a few uA?

RTC chips have a pin that outputs a square wave that can be set to various frequencies including 1Hz.
I can't remember if this works in low-power mode though.

The ds3231 has a 1Hz square wave option but it is on the same pin as the alarm interrupt.
I guess I will have to add a second rtc just for the display. :confused:

Perhaps a CMOS inverter oscillator using 74HC14 and 10Mohm / 100nF feedback path? The 74HC14 inverters
have hysteresis.

Thanks for your answers!
An oscillator with inverters sound much more elegant than wasting an entire rtc.
The 74HC14 would use up a bit too much space on the board but I found these 5 pin inverters:

Two of those, a resistor and a capacitor should fit nicely onto the board.
I think I will try both solutions and see which one draws less current.

Good news: I got a square wave out of a Schmitt Trigger Inverter (74HC1G14GW), a 10MOhm resistor and a 0.1uF cap. It is a bit faster than 1Hz but that doesn't matter. Here is a video with an Arduino hooked up to the output of the inverter to drive the internal LED:

The bad news: The critical part is how much current the oscillator draws. As the rest of the watch is at below 10uA in standby I wouldn't want the oscillator to draw more than that as well.
I added a few more capacitors to slow down the blinking and get a few 100 uAs. Also the current draw seemed to be constantly changing. I checked the datasheet(http://www.farnell.com/datasheets/1758114.pdf) and although the supply current is listed as 10uA max there is an additional supply current of up to 500uA if the input voltage is in between vcc or gnd. When inverters are used for debouncing buttons their inputs are either at a defined high or low. But for my application the input voltage constantly varies while the capacitor is charging or discharging. That would explain the high current consumptionto to me.
I don't know if this is a behavior that only this particular inverter has. In that case I am out of ideas. How hard can it be to toggle a pin? :confused:

This is entirely what is expected of a CMOS gate operating in the "linear" region.

It can be minimised by operating at the lowest supply voltage, thought the limited output voltage would then put the following chips into that undesirable region.

The design of the Schmitt HC14 should be such that the effect is less than with a non-Schmitt gate. You may actually find it preferable to try a three-gate oscillator instead, using non-Schmitt inverters. This should minimise the time spent in that linear region as feedback should occur as soon as it is approached.

Thank you for the clarification.
Do you think 10uA could be doable for a three gate oscillator like this:

I also found a very similar question on stackexchange:

Someone suggested a schmitt trigger oscillator using a NC7SZ14 and calculated a current consumption of around 1uA.
Either that is wrong or the NC7SZ14 somehow draws less current even while the cap is charged.

Wingman:
Do you think 10uA could be doable for a three gate oscillator like this:

Well, just try it. Resistor values should be something like 4.7M. Charging and discharging the capacitor is part of the current consumption.

Wingman:
Someone suggested a Schmitt trigger oscillator using a NC7SZ14 and calculated a current consumption of around 1uA.

Well, that particular device - whatever it is - may have different characteristics to the common 74HC14.

Just a quick update:

I thought about testing out other schmitt trigger inverters to see if they have a lower power consumption. As it turns out every schmitt inverter has a very high "delta Icc current" when used with a slowly changing voltage. There is a nice app note from TI about this:

Because of that I tried a different approach with a MCP7940 real time clock. After some testing it seems to provide a nice 1Hz signal with only about 2uA of supply current. This is even less than what I expected. I am not completely happy with this solution but the rtc is very cheap and doesn't use much space on the board.

Wingman:
I am not completely happy with this solution

Oh come on!

Why not?

:smiley: OK, I am pretty happy with it.
It's just that I am only using 5% of the RTC's functionality and a schmitt trigger oscillator would have been a more elegant solution.

When I have time I am going to test the new circuit with the display and see if that works.
Hopefully I can finish the project now.

I thought the RTC's functionality was to tell time.

So that means it keeps the time rather than your program, and your program is crash-proof. :grinning:

There already is an RTC on the board (a DS3231) for timekeeping and minute interrupts.
So with the new setup I need two RTCs, the cheap second one just for generating a 1Hz square wave.
Maybe I can use it for a hardware stopwatch function or something like that.

Update: New Problem

I assembled a new board with the mcp79410. Originally I intended to use the 32kHz square wave from the ds3231 as a clock source. But as it is an open drain output, I would need a low value pullup, which consumes too much current. I fixed this by using an external crystal.

The actual problem is that the 1Hz output from the mcp79410 is also open-drain. I was trying to save power by using a 1MOhm resistor but the screen still shows "burn-in". A 10k resistor works perfectly fine and the display stays normal. But I would be wasting 300uA. Even 100k would be too low. I don't really understand how this could be a problem since the signal is extremely slow.
Unfortunately I don't have an Oscilloscope at hand so it is difficult to see how the actual signal on the pin looks like.

Do you have any idea why 1Mohm does not work?

Display Datasheet: http://www.sharpmemorylcd.com/resources/ls013b4dn04_application_info.pdf

Because its asymmetric, not 50% duty cycle?

So the higher resistance means it takes longer to reach the high state than to reach the low state?
That would make sense since the display requires a very symmetrical change on the EXTCOMM pin.

Would it be possible to just add another 1MOhm resistor between display and rtc signal to cancel the pullup?
Edit: I tried this and it does not work. It 's no surprise since I basically built a voltage divider, so the display only gets 1.5 volts instead of 3. Any suggestions?

Edit: I have done more testing. I used another Arduino to toggle the signal at 0.1Hz and it still works. The screen shows no burn-in. That means 1Hz is not even necessary.
If I change the duty cycle of the 1Hz signal from 50% to 300ms/700ms it works as well. So the problem seems to not be the offset in duty cycle. I would guess that it's the rise time on the pin that is too slow to get recognized by the display.

Edit2: The rise time was indeed the problem. I asked the experts on stackexchange. The solution now is to use a low power schmitt trigger inverter to shorten the rise time on the pin. The polarity doesn't matter to the display anyway. I tried this with a NXP 74hc1g14gw and it works great. Problem solved.