Ice Tube Firmware Question

by neutron spin on Thu Aug 18, 2011 10:10 am

I noticed when the clock is unplugged and powered back up the brightness setting goes back to 3.0 (dimmest). Doesn't the memory retain the last brightness setting when power is lost?...Thanks...
neutron spin
 
Posts: 163
Joined: Sat Apr 03, 2010 5:11 pm

Re: Ice Tube Firmware Question

by adafruit on Thu Aug 18, 2011 12:33 pm

it does that immediately to save power
User avatar
adafruit
 
Posts: 11647
Joined: Thu Apr 06, 2006 3:21 pm
Location: nyc

Re: Ice Tube Firmware Question

by neutron spin on Thu Aug 18, 2011 12:47 pm

That is what I thought. I thought the earlier clocks did not have that feature. Perhaps my memory is not what it used to be :oops: ....Regards...
neutron spin
 
Posts: 163
Joined: Sat Apr 03, 2010 5:11 pm

Re: Ice Tube Firmware Question

by ib123 on Fri Aug 19, 2011 3:17 am

Once again I suggest that documenting how the clock is designed to behave after a power interruption would be very helpful for people purchasing the clocks and wanting to know what to expect from them.

Contrary to what is said here, my newly constructed clock remembers all its settings including brightness when I unplug the clock and plug it back in.
ib123
 
Posts: 11
Joined: Sun Aug 14, 2011 2:02 pm

Re: Ice Tube Firmware Question

by neutron spin on Mon Aug 22, 2011 12:53 pm

OK...I am all ears....So which is it?...My clock VS. others.....Mine reverts back to 3.0 when power is lost...this is of course is with the latest firmware installed and yes the battery is installed.......Adafruit says yes it does go back to 3.0...but????....
neutron spin
 
Posts: 163
Joined: Sat Apr 03, 2010 5:11 pm

Re: Ice Tube Firmware Question

by ib123 on Mon Aug 22, 2011 2:27 pm

When I was unsure if my backup battery was working I unplugged the power and then measured the voltage on C4 (easiest to measure this on the C4 side of D4).

I don't know how to tell which firmware is in the chip as there is no version number indication on the menu system, but my clock was purchased very recently.

There is no reason to change the display brightness when unplugging the clock as the display will switch off as soon as main power disappears and the backup battery then only needs to supply the 5 V logic parts of the circuit.
ib123
 
Posts: 11
Joined: Sun Aug 14, 2011 2:02 pm

Re: Ice Tube Firmware Question

by neutron spin on Mon Aug 22, 2011 5:42 pm

Wow...more weirdness!....powered down clock again and it remembered this time the brightness setting...for some odd reason the memory does not always capture the brightness setting...everything else works fine...time is accurate and battery backup appears to be working....oh well...does it really matter? :roll: ....regards...
neutron spin
 
Posts: 163
Joined: Sat Apr 03, 2010 5:11 pm

Re: Ice Tube Firmware Question

by adafruit on Mon Aug 22, 2011 7:28 pm

it all depends on how fast power is lost. really, the battery backup is optimized for the time not for saving the brightness settings. keep the clock plugged in at all times, dont constantly unplug/replug it because eventually it may miss saving the time to eeprom before power is lost.
User avatar
adafruit
 
Posts: 11647
Joined: Thu Apr 06, 2006 3:21 pm
Location: nyc

Re: Ice Tube Firmware Question

by neutron spin on Tue Aug 23, 2011 11:55 am

Thanks Adafruit for the explanation. I wasn't trying to break the clock :oops: ...just noticed the quirk....makes sense... :D
neutron spin
 
Posts: 163
Joined: Sat Apr 03, 2010 5:11 pm

Re: Ice Tube Firmware Question

by ib123 on Tue Aug 23, 2011 12:28 pm

I guess I don't understand the design of this clock yet. Why would the clock want to save the time in the EEPROM? Surely the clock needs to keep the time, not freeze the time? For the brightness setting and other settings, why not save them to EEPROM as soon as you change them, rather than waiting for a power interruption before doing so? Is there a limited number of write cycles on the EEPROM that discourages frequent writes?

My preferred behavior would be for the clock to go into standby mode on loss of main power and come back just where it left off after power is returned. I don't see a need for it to beep and blink the display on power restoration except after a cold reset.

It seems there is a little project in my future to learn how to modify and reprogram the clock firmware. I would like to add a time adjust fast/slow feature to the menus when I do so to fine tune the time keeping.
ib123
 
Posts: 11
Joined: Sun Aug 14, 2011 2:02 pm

Re: Ice Tube Firmware Question

by jarchie on Mon Dec 03, 2012 7:36 pm

I never noticed any issues with remembering brightness settings after power loss. My clock was purchased in December 2011.

From examining the Adafruit code and my own personal experience with the clock, I believe the official firmware saves the time and restarts the clock after a power outage. After the restart, the firmware loads the saved time, detects the low power condition, and sleeps, waking once-per-second to update the time. I suspect that, while sleeping, the once-per-second interrupt periodically fails to wake the clock. When this happens, the watchdog timer detects a lockup and resets the clock, sometimes resulting in noticeable time loss. When power is restored, the clock once again saves the time, restarts, loads the saved time, and otherwise runs normally.

EDIT: I was using the term "reset" loosely. What happens is a "software restart" by calling the function "void (*app_start)(void) = 0x0000;" which is defined in iv.h. This simply jumps to the very first instruction, which is like a reset except that registers values may persist.

After writing an alternative Ice Tube Clock firmware with the behavior described by ib123 (no restarting or blinking on power loss), I can say that reliably waking from power save mode with asynchronous timer interrupts is surprisingly tricky. But for those attempting to do so, the following suggestions may help:

First, before sleeping, ensure all timer2 registers have been written. If they have not, the system may not wake.

Code: Select all | TOGGLE FULL SIZE
while(ASSR & (  _BV(TCN2UB) | _BV(OCR2AUB) | _BV(OCR2BUB) | _BV(TCR2AUB) | _BV(TCR2BUB) ));


Second, the code in the once-per-second interrupt must take at least one quartz clock cycle to execute (32.768kHz or 30.5 microseconds), or the interrupt may be triggered more than once per second. If in doubt, set one of the timer2 registers in the code, and the while loop above will prevent the system from sleeping before the value is written, which takes more than once quartz clock cycle. For example, the following line could be placed in the once-per-second interrupt handler.

Code: Select all | TOGGLE FULL SIZE
OCR2B = 0;


Third---and I found no mention of this in the ATmega168 or ATmega328p datasheets---waking from sleep is unreliable if any of the timers are disabled in the power reduction register (PRR). So enable and disable timer0 and timer1 with the timer configuration registers (TCCR0A, TCCR0B, TCCR1A, and TCCR1B), and leave all timers enabled in the power reduction register.

Fourth---and this is done correctly in the official firmware---divide the system clock by at least four during sleep as higher clock speeds may prove unstable at lower voltages. Some people recommend dividing the clock by the maximum possible amount to reduce power consumption while running code, but this also forces the microcontroller to spend more time running code and less time sleeping. In my firmware, the microcontroller used less power while sleeping with a faster clock speed. So grab your multimeter, try it both ways and do whatever is more efficient.

Code: Select all | TOGGLE FULL SIZE
#include <avr/power.h>
// ...
clock_prescale_set(clock_div_4);


EDIT: The datasheet also specifies that "The CPU main clock frequency must be more than four times the Oscillator frequency," so do not divide the system clock by more than 32. The official firmware divides the 8 MHz internal clock by 256 during sleep, resulting in CPU clock of 31.250kHz. This seems to work fine in practice, but violates the datasheet.

Fifth and finally, I do not think there is much need to optimize the power-loss interrupt for speed, as previously suggested. The power supply capacitors are reasonably large and the ATmega168v executes code quickly. My power-down-and-sleep code is rather inefficient, but still seems to work reliably without loosing time...

Well... I hope someone finds this information helpful. Cheers!
--John <www.jarchie.com/email>
jarchie
 
Posts: 403
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States