AVR and ISP

Schematic

The ATMEL ISP programming standard is a 6 pin header, from the AVR Hardware Design Considerations appnote.  This pinout is used on the STK500.  Unlike some protocols (eg. RX and TX) there is no need to swap the MISO and MOSI lines when wiring up the header.  The stk500 is able to have LEDS and switches connected to the mcu during programming.  Experiments show that LEDS on the MOSI and MISO lines without R1 and R2 break ISP.  Any devices on the SPI ports need to be isolated by a resistor (see Section 4 of the appnote).

STK500 and ATTiny13 @ 128kHz

The ISP programming frequency must be at least 1/4 the target clock frequency (datasheeet).  For an ATTiny13 running at 128kHz (for power saving) the SCK period should be at least 32 us.  Another online source offers the following hookup for programming attiny13s with an stk500:

• Connect ISP6 to SPROG1 with a 6-pin cable;
• Connect PORTE.RST to PORTB.PB5 with a 1-pin cable;
• Connect PORTE.XT1 to PORTB.PB3 with a 1-pin cable;
• Set ISP frequency (in AVR Studio STK500 menu) to 1/5 the target clock  frequency, or lower. (By default, target clock frequency is 9.6 / 8 = 1.2  MHz.)

1/5 target clock frequency for 128kHz clock would yield SCK = 39.  This is an interesting discussion on programming the attiny13 at low clock speeds:

http://www.nabble.com/Slow-communication-with-ATTiny13-td12775912.html

While this seems straight forward, in practice once the lfuse is changed from 0x6A to 0x6B (CLKSEL=11 or 128kHz internal), the stk500 with an sck=40 is unable to communicate with the chip.  Initially, communication was restored using:

• fosc = 128000 (stk500 rewrites as 131kHz)
• sck = 40
• avrdude option i=40

Then suddenly this no longer worked.  From the attiny13 datasheet:

The 128 kHz internal Oscillator is a low power Oscillator providing a clock of 128 kHz. The frequency depends on supply voltage, temperature and batch variations. This clock may be select as the system clock by programming the CKSEL fuses to “11”.

So it would seem that the clock frequency may or may not be 128khz.  After through testing, it was determined that the i=40 option has no effect.  Given that the clock frequency is essentially unknown, the only way to restore communications is to max out SCK:

• fosc = 131.657
• sck = 276
• avrdude option ‘i’ not used

It should also be noted that things were restored after trying to read out all the flash memory, then adjusting the stk500 parameters as above.   The flash dump does not complete before the stk500_2_ReceiveMessage(): timeout.  The timeout also happens when programming larger files into flash.  Not sure if the read cycle is related, but thought it should be noted.  Timouts also occur with these settings programming an ATMeg8151.  Use these settings instead:

• fosc = 1.229 Mhz
• sck = 9.8 us
• vtarget/vareg = 5.0V

Power Consumption

Ideally this would run from a CR2032 lithium button cell battery.  The circuit above, with LED1 not connected, draws 12mA.  The CR2032 specs indicate 12mA is the maximum recommended pulse discharge, and 4mA is the max. continuous discharge rate.  That means currently this 220mAh battery will only last 18 hours.  If the design can be tweaked to run at 4mA, the run time would be 55 hours. Rechargeable AA batteries have capacity 2100 – 2600 mAh, which could run for about a month.

Options for minimizing power consumption are listed in the datasheet in section 7.2.  The A/D convert, BOD, and watchdog are all turned off by default.  Only the analog comparator must be disabled.  Setting unused pins to inputs and enabling internal pull ups is also recommended.