Electronic – How to a micro controller turn off itself by closing the VCC line when battery is low

It is likely that your computer system is "charging" the battery when powered on and causing the problem. See (2) below.

(1) If battery charging as discussed below is not the problem then the remaining choices appear top be bad environment or excessive load. The RTC load in backup mode should be under 2 uA (1.6 uA max at 25C, 5 uA max across temperature range) according to the ISL12020M RTC datasheet that you cited. Battery capacity of the Energizer CR1220 cell that you cite should be in excess of 45 mAh at 1.8V endpoint and over 42 mAh is you use a series Schottky diode. Even using a series silicon diode such as a 1N4148 (with much lower reverse leakage than a Schottky diode) will give more than 41 mAH. I say "more than" in each case as this is based on the supplied curve at 62k ohm load or around 40 uA - so you should get usefully more capacity at around 2 uA.

5 uA at say 40 mAh = 8000 hours and the more likely < 2 uA = 20,000 hours, so the experienced corrosion problems after a few months use do not point to battery overload stress being the source of corrosion.

Which leaves environment. Are the battery holders formal ones and correct for this cell - ie are the materials compatible? Is there a corrosive atmospheric component?

You could try placing two cells in two holders loaded with say 330k ohm and 1 megohm for about 10 uA and 3 uA initial currents and place them in a sealed container with dessicant, and two more similarly loaded cells located within the equipment involved with exposure to the air.

Spraying the battery assembly with a complete but not too generous coating of polyurethane clear enamel (or a formal conformal coating of your choice) would help establish whether the corrosion came from without or within.

Does the corrosion product match the electrolyte of the cell?

What temperature ranges are being experienced.

(2) Battery charging?

Measure the battery voltage out of circuit.
Power the PC and measure the peak output voltage on the battery terminals that occurs with the battery out of circuit at any time during operation.
If V_PC_max > V_battery by even a small amount then you are charging the battery and violating the reverse charge spec.

If charging is occurring (which seems likely) options are - a different battery technology or a series Schottky diode. The diode will reduce available battery capacity relatively slightly (see calculations above) and may be acceptable but need system modification in some way. A small silicon diode would also probably be acceptable and would reduce reverse current even more.

Sharptooth asked:

Why will connecting a diode in series reduce the available battery capacity?

The diode reduces the available voltage by "one diode drop". As the battery voltage decreases a point will be reached where it is no longer adequate for the task. When a diode is in series with the battery feed the point of lowest useful voltage will be reached when the actual battery voltage is still one diode drop above this voltage. How much of the capacity is wasted by this loss of voltage depends on the general battery characteristics, the load minimum voltage requirement, and the shape of the battery curve at different load levels.

For a typical CR1220 Lithium Manganese Dioxide cell characteristics see this Maxell CR1220 datasheet

Two graphs from this data sheet are copies below as Fig 1A and Fig2A.
Modified versions with output voltage reduced by one diode drop are shown as Fig 1AB and Fig 2B.
I have changed the voltage by roughly 0.3 - 0.4V. A Schottky diode's voltage drop depends on current drain and diode characteristics and as small as 0.3VF to 0.4V is typical enough at low currents. Even lower may happen, but no guarantees.

Fig 2A / 2B gives a good example of the effect of adding a diode. Fig 2A is a discharge curve set with the battery alone and for FRig 2B I have offset the curves downwards by about 0.4V to simulate the drop in a series diode.

As an example, imagine that a load required at least 2 V output.
The blue vertical lines show where the output voltage drops under 2V for a 0 degrees C discharge with 30 kOhm load for the original battery ~= 380 hours, and with a diode ~= 325 hours. The reduction due to the diode = (380-325)/380 x 100% =~ 7%.
At -10C the durations are about 340 and 280 hours or a reduction of ~= 18%.

The results will vary with Vcutoff, Rload,temperature and more.

The most signmificant results will occur when a load needs a relatively high voltage that is not much less than the Vout over most of the capacity range. eg in Fig1A if the load required 2.75V minimum then an 82k load would last about 700 hours anhd a 5.6M load would last about 40,000 hours with the battery alone.
BUT with a series diode as shown, anything under 1 MOhm would not run at all and a say 5.6 MOhm load would be touch and go - ie may not run at all and may run for 10,000 + hours depending on variations in cells.

I dont understand your confusion. You want to communicate between the two controllers with UART, then ofcourse both of them need UART capabilities and code for this. Your computer has drivers and software for dealing with this, so your microcontroller also needs a driver for it.

Your ATmega32 need UART TX functionality, while AT90USB1287 need UART RX functionality. Having already written both TX and RX for your ATmega32, writing the UART RX routine for AT90 should be a breese. You could add a bitvalue of some kind, identifying that the UART RX on AT90 is coming from your ATmega32, and directly pass it through to USB.

EDIT: Code from AVRFreaks that is written for at90usb1287

#include <avr/io.h> 
#include <util/delay.h> 

#define RXC      (RXC1) 
#define TXC      (RXC1) 
#define UCSRC    (UCSR1C) 
#define UCSRB    (UCSR1B) 
#define UCSRA    (UCSR1A) 
#define UDR      (UDR1) 
#define UBRRL    (UBRR1L) 
#define UBRRH    (UBRR1H) 
#define UBRR     (UBRR1) 
#define UDRE     (UDRE1) 
#define RXCIE    (RXCIE1) 
#define TXEN     (TXEN1) 
#define RXEN     (RXEN1) 
#define UCSZ0    (UCSZ10) 
#define UCSZ1    (UCSZ11) 
#define UMSEL0   (UMSEL10) 
#define UMSEL1   (UMSEL11) 

#define FRAMING_ERROR (1<<FE1) 
#define PARITY_ERROR (1<<UPE1) 
#define DATA_OVERRUN (1<<DOR1) 
#define DATA_REGISTER_EMPTY (1<<UDRE1) 
#define RX_COMPLETE (1<<RXC1) 

#define FOSC 16000000 

typedef unsigned char       Uchar; 
typedef unsigned long int   Uint32; 

#define Wait_USART_Ready() while (!(UCSR1A & (1<<UDRE1))) 

#define lowByte(w) ((uint8_t) ((w) & 0xff)) 
#define highByte(w) ((uint8_t) ((w) >> 8)) 

int main(void) 
{ 
/* Disable clock division */ 
clock_prescale_set(clock_div_1); 
   UBRRH = (Uchar)((((Uint32)FOSC)/((Uint32)USART_BAUDRATE*16)-1)>>8); 
   UBRRL = (Uchar)(((Uint32)FOSC)/((Uint32)USART_BAUDRATE*16)-1) & 0x0ff; 

   UCSRB |= (1 << RXEN) | (1 << TXEN); 
   UCSRC |= (1 << UCSZ1) | (1 << UCSZ0); 

   char ReceivedByte; 
   for (;;) // Loop forever 
   { 
      while ((UCSRA & (1 << RXC)) == 0) {}; // Do nothing until data have been received and is ready to be read from UDR 
      ReceivedByte = UDR; // Fetch the received byte value into the variable "ByteReceived" 

      while ((UCSRA & (1 << UDRE)) == 0) {}; // Do nothing until UDR is ready for more data to be written to it 
      UDR = ReceivedByte; // Echo back the received byte back to the computer 
   } 
}