ATtiny programming a function - appears to freeze

Question

I am new to programming ATtiny chips. I ran the equivalent program to this on an Arduino and it worked, but when running it on an ATtiny2313, although no error message appears, the program appears to freeze. All of PORTB is connected to LEDs, and when the program runs, the alternate LEDs light, but then they stay on instead of swapping.

I am using a makeFile, AVRdude and USBtinyISP programmer to program the ATtiny.

I figure there must be something slightly wrong with the program, I would be very grateful of any help.

Thanks

Stephen

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

void myFunction(int status){
  if(status==1){
    PORTB = 0b10101010;
  }else{
    PORTB = 0b1010101;
  }
  int i;
  for(i=0; i<100; i++){
    _delay_ms(10);
  }
  return;
}

int main(void){
    DDRB = 0xFF;
    while(1){
        myFunction(1);
        myFunction(0);
    }
    return 0;
}

My Makefile is:

DEVICE     = atmega8
CLOCK      = 8000000
PROGRAMMER = #-c stk500v2 -P avrdoper
OBJECTS    = main.o
FUSES      = -U lfuse:w:0xe4:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

# ATMega8 fuse bits used above (fuse bits for other devices are different!):
# Example for 8 MHz internal oscillator
# Fuse high byte:
# 0xd9 = 1 1 0 1   1 0 0 1 <-- BOOTRST (boot reset vector at 0x0000)
#        ^ ^ ^ ^   ^ ^ ^------ BOOTSZ0
#        | | | |   | +-------- BOOTSZ1
#        | | | |   +---------- EESAVE (set to 0 to preserve EEPROM over chip erase)
#        | | | +-------------- CKOPT (clock option, depends on oscillator type)
#        | | +---------------- SPIEN (if set to 1, serial programming is disabled)
#        | +------------------ WDTON (if set to 0, watchdog is always on)
#        +-------------------- RSTDISBL (if set to 0, RESET pin is disabled)
# Fuse low byte:
# 0x24 = 0 0 1 0   0 1 0 0
#        ^ ^ \ /   \--+--/
#        | |  |       +------- CKSEL 3..0 (8M internal RC)
#        | |  +--------------- SUT 1..0 (slowly rising power)
#        | +------------------ BODEN (if 0, brown-out detector is enabled)
#        +-------------------- BODLEVEL (if 0: 4V, if 1: 2.7V)
#
# For computing fuse byte values for other devices and options see
# the fuse bit calculator at http://www.engbedded.com/fusecalc/


# Tune the lines below only if you know what you are doing:

AVRDUDE = avrdude $(PROGRAMMER) -p $(DEVICE)
COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)

# symbolic targets:
all:    main.hex

.c.o:
    $(COMPILE) -c $< -o $@

.S.o:
    $(COMPILE) -x assembler-with-cpp -c $< -o $@
# "-x assembler-with-cpp" should not be necessary since this is the default
# file type for the .S (with capital S) extension. However, upper case
# characters are not always preserved on Windows. To ensure WinAVR
# compatibility define the file type manually.

.c.s:
    $(COMPILE) -S $< -o $@

flash:  all
    $(AVRDUDE) -U flash:w:main.hex:i

fuse:
    $(AVRDUDE) $(FUSES)

# Xcode uses the Makefile targets "", "clean" and "install"
install: flash fuse

# if you use a bootloader, change the command below appropriately:
load: all
    bootloadHID main.hex

clean:
    rm -f main.hex main.elf $(OBJECTS)

# file targets:
main.elf: $(OBJECTS)
    $(COMPILE) -o main.elf $(OBJECTS)

main.hex: main.elf
    rm -f main.hex
    avr-objcopy -j .text -j .data -O ihex main.elf main.hex
    avr-size --format=avr --mcu=$(DEVICE) main.elf
# If you have an EEPROM section, you must also create a hex file for the
# EEPROM and add it to the "flash" target.

# Targets for code debugging and analysis:
disasm: main.elf
    avr-objdump -d main.elf

cpp:
    $(COMPILE) -E main.c

This was the default file, I haven't changed any of the original settings.

Answer 1

Your code looks correct. The most likely problem is that it's being built incorrectly, but to address this we need to see your Makefile.

At the link below (wouldn't let me post the link so you have to copy/paste it yourself) is a post by someone who had a very similar problem to yours. It turned out that he was not running his compiled object file through the linker, with the result that some essential library was missing which caused the PIC to loop endlessly, trying to execute an invalid opcode (instruction).

efreedom dot com/Question/E-27081/Using-Avr-Gcc-Delay-Ms-Causes-Chip-Freeze

If this doesn't fix it, try posting your Makefile.

Also, there is no reason to call _delay_ms(10) 100 times, you can just call _delay_ms(1000) directly. It will use a lower resolution.

Edit: After seeing your Makefile it looks like your clock speed might be set incorrectly. The CLOCK setting specifies what speed you are running your AVR at, if it's set to something way off (like 8MHz and your PIC is running at 1MHz), the delay loop will take 8 seconds when you expect it to take one - if that's the problem your LED's will appear frozen but if you wait long enough they will actually change. Try removing the -DF_CPU=$(CLOCK) statement and see if it makes a difference.

Apart from that your Makefile has a lot of unused/unnecessary stuff, and since I don't have a working avr-gcc setup at the moment, it's hard to follow, so it will help if you try simplifying the Makefile like the following, and see if it works - it will be close, please comment below if you get any problems!

DEVICE     = attiny2313
CLOCK      = 8000000
OBJECTS    = main.o

# Tune the lines below only if you know what you are doing:

AVRDUDE = avrdude $(PROGRAMMER) -p $(DEVICE)
COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)

# symbolic targets:
all:    main.hex

flash:  all
    $(AVRDUDE) -U flash:w:main.hex:i

clean:
    rm -f main.hex main.elf $(OBJECTS)

main.elf: $(OBJECTS)
    $(COMPILE) -o main.elf $(OBJECTS)

main.hex: main.elf
    rm -f main.hex
    avr-objcopy -j .text -j .data -O ihex main.elf main.hex
    avr-size --format=avr --mcu=$(DEVICE) main.elf

Answer 2

The first line of your Makefile specifies the wrong chip.