Strange atmega8a-pu pin behavior problem when uploading a sketch - Solved

Hey,
I won’t make this post long. Here’s the situation:

  • Burn bootloader successfully (also tried optiboot and it worked)
  • Upload blink sketch using int led = 9
  • Led blinks on pin 9 (PB1)!
  • Upload blink sketch using int led = 10
  • Led doesn’t blink on pin 10 (PB2) <-------------- Problem starts here!
  • Led blinks on pin 8 (PB0) - huh?
  • Upload sketch using some other pin and only pin 8 works / sometimes none work
  • Reburn the bootloader and the led blinks on e.g. pin A5 if set in sketch (but not after 2nd upload) :confused:
  • The problem starts again

I don’t have a problem with uploading or burning the bootloader to the atmega8a-pu, but the pins misbehave after the 2nd upload. I have a external 16mhz xtal hooked up (8mhz internal also works).
I’m hoping that someone might recognize the problem and have a solution. I’ve tried looking and haven’t found anything yet. Obviously I could always burn the bootloader everytime before uploading my code, but it feels a bit unnecessary. Could this be something to do with pin assignments getting mangled up? I apologize if this question has been asked before or if I’ve overlooked the solution.

I have had this behaviour with a standalone (first upload behaves different then next uploads). It had to do with bad connections, badly decoupled power, bad power supply, bad connections with crystal or the 22pf, bad signals of the RX and TX of the usb-serial-ttl board. It seems that there is some kind of mysterial logic behind this behaviour, but that doesn't have to be so. When using a breadboard without any capacitor for the power supply, this is what can be expected.

Do you use a library or register for the blinking ? The registers are not the same as the ATmega328p. Are you sure the bootloader is okay ? Which one, with what options ? How are the fuses set in boards.txt ? Could you upload a photo of it ? Do you use the RX and TX to upload a sketch ?

This is the sketch that gets the led blinking after a fresh bootloader burn.

int led = 9;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

I’m using the Arduino UNO with the arduinoisp configuration to talk with the atmega8a-pu.
boards.txt:

atmega8o.name=[Optiboot] Arduino NG or older w/ ATmega8
atmega8o.upload.protocol=arduino
atmega8o.upload.maximum_size=7680
atmega8o.upload.speed=19200
atmega8o.bootloader.low_fuses=0xbf
atmega8o.bootloader.high_fuses=0xcc
atmega8o.bootloader.path=optiboot
atmega8o.bootloader.file=optiboot_atmega8.hex
atmega8o.bootloader.unlock_bits=0x3F
atmega8o.bootloader.lock_bits=0x0F
atmega8o.build.mcu=atmega8
atmega8o.build.f_cpu=16000000L
atmega8o.build.core=arduino:arduino
atmega8o.build.variant=arduino:standard

I am using the latest optiboot collection (5.0a)

I have also used the ‘stock’ arduino IDE atmega8 bootloader (with the long initial wait for code to execute).
With all configurations the led code goes through and usually starts executing, but eventually works only on pin 8.’
In the pic I have a 10uH cap over reset and GND, I know it works without it while on the xtal.

Are you sure those are 22pF (or 20pF) ? The capacitors look rather large. The crystal + 22pF + ground to avr chip should be close to each other. Between the 22pF and the GND of the avr chip is some distance (the wires of the capacitor and the ground wires). Could you make that shorter ? Move the crystal a little and put the ground legs of the 22pF directly next to the avr chip.

Could you add decoupling capacitors of 100nF and a capacitor 22uF .... 1000uF to the 5V and GND ?

Without decoupling, any result is invalid. I also don't know what the influence of the Arduino Uno is. I use a USBasp programmer and a usb-serial-ttl converter for my standalone.

Thanks for the help. I couldn’t get the problem solved yet (tried shorter cables and the decoupling). However I found some avrdude output that might help:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0378
         0x0a != 0x08
avrdude: verification error; content mismatch
avrdude: Send: Q [51]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [10] 

avrdude done.  Thank you.

This is right after changing the pin from 9 to 10. Also I realized that as long as I keep uploading the exact same sketch (with e.g. pin 9), there is no problem. When I change the pin in the code, the problem starts and reverts to pin 8. Could it be that bits get locked? How can I fully erase my bootloader (burn empty)?

When you upload a sketch via the programmer ( that option is in the menu ), the bootloader is replaced with the sketch.

A breadboard can have bad connections. Can you measure the voltage on the avr chip, to see if they are okay ?

There should be no content mismatch. avrdude seems to have bad communication with the avr chip. Could you try with the original Arduino NG Atmega8 ? That bootloader and fuses are okay. I didn't check the fuse settings in your post, some use different fuses which is okay.

Whoah everything works now with the File -> Upload Using Programmer option from the Arduino IDE! I've programmed attiny85's before and had never used that menu option before. Thanks for the help. Here's a similar post I just found, wish it had been earlier...

http://forum.arduino.cc/index.php/topic,85126.0.html

Were you uploading the sketch with the Upload command? (As opposed to Upload With Programmer.) I don't see any serial connections in your breadboard pic...

When I build standalones, I put the Xtal and its load caps off to the side of the AVR chip, like down by pin 14/15. I use the same vertical group (the numbered columns on the breadboard) for the cap grounds, then run a single wire from that to the ground strip. The Xtal pins connect to the AVR with short jumpers (usually the kind that are color-coded to multiples of 0.1" and sit flat against the board.) Not sure if that's the best way, but it works well for me.

I use a 10uF (for USB-powered) or 100uF (for wall-wart powered) electrolytic cap on the power rails of the breadboard. Also, 0.1uF (100nF) ceramic caps between Vcc and Gnd (or on the +/- rails, on the space right next to where I put the Vcc/Gnd jumpers if space is tight). Same for the AVcc and Aref pins.

Not sure what the cap on the reset header is supposed to be doing, but sometimes there are little tricks like that I haven't heard of, so maybe you have a good reason. (If so, enlighten me!) I don't ever use one on reset myself, unless it's in series with the DTR line on an FTDI cable...

Yeah I was completely unaware of the upload with programmer option. It's about 2 years now since I last programmed an standalone avr. It was an attiny85, for which I used the upload command to push the code. The 10uF cap is from those times, it is (was?) necessary to keep the reset from triggering unintentionally while talking to the target avr (I could be wrong) using the UNO board as an programmer. You shouldn't need the 10uF cap if you're using an xtal (at least with the atmega8). I'm working on a HF radio receiver project where the atmega8 and the vast pin count come handy (e.g rotary encoders, SPI and analog inputs). Speaking about steady voltages, short leads and decoupling capacitors, I think my signal grooming headaches are yet to come :)