3

I have the blink code below running on an attiny24 with the default fuses, via Atmel Studio 6. If I set DDRA to any combination of 5 pins (or set DDRA to 0xFF and then blink by setting PORTA to any combination of 5 pins) then it works but as soon as I use 6 pins it resets itself. The PORTB.0 toggle at start up demonstrates the reset.

The usual cause for this sort of behaviour is sourcing or sinking too much current on the outputs, however this is happening when the outputs are left open, nothing attached, so I can't see what's causing it. Any suggestions?

int main(void)
{
  // DEBUG: Toggle PORTB.0 to demonstrate AVR reset.
  DDRB = 0x01; PORTB ^= 0x01; _delay_ms(10); PORTB ^= 0x01;

  // Output 6 pins at once (change to 5 pins and AVR does not reset).
  DDRA = 0b00111111;
  for (;;)
  {
    PORTA = 0xff;
    _delay_ms(1000);
    PORTA = 0x00;
    _delay_ms(1000);
  }
}

I've tried the usual suspects, power supply, running with AVRISP disconnected and ensuring there is a cap between +VE and GND. Also tried setting pins individually and as soon as it hits 6 it resets.

Schematic - note LED is just for debugging

dibnah
  • 41
  • 3
  • Is it a specific sixth pin every time? – David Dec 03 '13 at 09:19
  • It doesn't seem to be, I've tried lots of combinations, especially around the MOSI, MISO and SCK pins, but it's just based on quantity. – dibnah Dec 03 '13 at 10:24
  • Can you post a circuit diagram / picture of your setup? – John U Dec 03 '13 at 11:02
  • 3
    Is the reset pin floating? You could have capacitive coupling from adjacent pins causing the MCU to reset. – Connor Wolf Dec 03 '13 at 11:20
  • I've attached the schematic, it does the same thing whether ISP, LED or cap is attached. Good suggestion on the reset pin thanks Connor, I tried a 10k pullup on reset, even a 100n cap to ground and diode as in the app notes but it still does the same thing. – dibnah Dec 03 '13 at 12:01
  • Seems like you've done the usual steps, I wonder if it's worth toggling say PA0 - PA3 and measuring the output voltage on each individual pin compared to say just toggling PA0. Maybe it's some sort of internal fault causing them to sink or source too much, or have you already tried a different device? – PeterJ Dec 03 '13 at 12:19
  • Thanks Peter, interestingly I got the same result with another 20PU version of the chip, I just found a 10PU and it works on that one. I'm determined to get to the bottom of this though, so I'll try your suggestion measuring PA0-PA3. brb. – dibnah Dec 03 '13 at 14:36
  • 2
    Got it! That 10PU/20PU difference indicated a voltage drop problem, so I moved the cap directly between +ve and gnd on the chip (it was one jumper wire away on the breadboard). Technically a schoolboy error as the app notes do recommend putting the cap there. Something internal must be need that extra juice when turning all the pins on but it seems odd given they're they're not loaded. Thanks to all for the insight. – dibnah Dec 03 '13 at 14:43

1 Answers1

1

The problem is that there is a spike when turning on all the pins, even though they are not loaded, and this sapped enough power to cause a brown out.

The Atmel design notes specify the cap should be as close to the pins as possible and it worked when I put a 100nF cap directly on the chip's VCC and GND on the breadboard. There wasn't a huge gap between the chip and my power rails, just over an inch, so this shows how important it is place the cap correctly.

I've used a lot of AVRs and this one seems particularly unforgiving in this aspect, especially as the outputs were not drawing any current externally.

dibnah
  • 41
  • 3