Electronic – AVR (attiny24) resets itself driving more than 5 outputs under no load

avr

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

Best Answer

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.

Related Solutions

Electronic – Using avr-gcc _delay_ms causes chip to freeze

I suspect the problem is not with your C code but with your Makefile.

The following lines in your Makefile produce an example.o object file.

main:
    avr-gcc -g -Os -Wall -mmcu=atmega328 -c ../src/example.c

The created .o file only contains the symbols and code from example.c, not the additional source required to actually make it run on a target system such as interrupt vector jump tables and code to initialise the BSS RAM segment to zeros, and load your initialised data sections.

You'll need to add an additional line something like this to run the linker and produce an output object suitable for download to the AVR part. Alternatively, use avr-ld, but you'll have to work out all the required linker options.

main.elf: example.o
    avr-gcc example.o -o main.elf

You can use avr-objdump --disassemble-all <filename> on both example.o and main.elf yourself to verify the different content of each file.

It's always a good idea to try to reduce your problem in steps to the most simple example possible. In this case, it would probably mean dropping into the AVR Studio software and creating a project running on the simulator using their managed build process. From there, you could them export the Makefile in use by their build process by using the 'Export Makefile' menu option. The generated makefile could then be compared with your version.

Actually, it's probably a good idea to use a Makefile similar to the one generated by AVR Studio because it has the correct rules already defined, you just have to set up some variables with regard to which objects need to be generated and the final target file name.

Electronic – Looking for AVR MCU with internal PLL clock source with more than 8 pins

There are several AVRs with more than 8 pins, that incorporate the PLL clock multiplier based on the internal RC oscillator. Unfortunately, this is not one of the parameters that can be searched for on the Atmel site.

There is, however, a work-around:

Search through all the include files (*.h) in your AVRGCC installation folder for the string PLLCSR. The headers for the AVR parts which do have the PLL will show up. After that, you would still need to go through the datasheets of that subset to check for number of pins, and to check for a line like this:

On chip PLL for fast PWM (32MHz, 48MHz, 64MHz) and CPU (12MHz, 16MHz); PLL source RC & XTAL

On a quick scan, I found the AT90PWM81/161 to meet the requirements, there are several others too.