Older

• Nov 23, 2009

  issue 10 (stk500 not in sync) commented on by rsbohn   -   Do not press the RESET button on the Arduino. The Arduino needs to be running the mega-isp firmware before you run avrdude.

  Do not press the RESET button on the Arduino. The Arduino needs to be running the mega-isp firmware before you run avrdude.
• Nov 23, 2009

  issue 13 (Duemilanove programming Attiny85 succeeds but doesn't work) Status changed by rsbohn   -   Glad that it is working for you!

  Status: Done

  Glad that it is working for you!

  Status: Done
• Nov 19, 2009

  issue 13 (Duemilanove programming Attiny85 succeeds but doesn't work) commented on by haggardii   -   The defect, dear sirs, is with the human. I was doing: avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 instead of avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 -U flash:w:myblinky.hex No wonder it wasn't working :) It now works wonderfully!

  The defect, dear sirs, is with the human. I was doing: avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 instead of avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 -U flash:w:myblinky.hex No wonder it wasn't working :) It now works wonderfully!
• Nov 18, 2009

  issue 13 (Duemilanove programming Attiny85 succeeds but doesn't work) reported by haggardii   -   -------------------- Steps to dupe: -------------------- 1. Using Arduino-0016, program Arduino Duemilanove (Duey) with mega-isp. 2. Hook Duey to Attiny85 (Tiny): Duey Tiny 13 pin7 (PB2 / SCK) 12 pin6 (PB1 / MISO) 11 pin5 (PB0 / MOSI) 10 pin1 (PB5 / Reset) 3. Power Tiny with 5V (independent of Duey) 0V pin4 5V pin8 4. Compile and program Tiny: avr-gcc -mmcu=attiny85 -Wall -I./ -o myblinky.out matt.c avr-objcopy -j .text -O ihex myblinky.out myblinky.hex avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.13s avrdude: Device signature = 0x1e930b avrdude: safemode: Fuses OK avrdude done. Thank you. 5. Disconnect Duey from Tiny. Connect reset to VCC. -------------------- Expected output -------------------- I expect 5V on Tiny's PB4 (pin 3) or PB3 (pin 2). -------------------- Actual output -------------------- Tiny: 4.9V pin1 PB5 (reset) 0.4V pin2 PB3 0.3V pin3 PB4 0.0V pin4 GND 0.4V pin5 PB0 (MOSI) 0.4V pin6 PB1 (MISO) 0.4V pin7 PB2 (SCK) 4.9V pin8 VCC Duey: pin7 (heartbeat) LED slowly pulsing pin8 (error) LED never comes on pin9 (programming) LED on while programming, now off -------------------- Other info -------------------- Ubuntu 9.04 $ avrdude -v avrdude: Version 5.5, compiled on Jan 28 2009 at 10:40:52 Here's the fuse data: $ cat efuse.dat 0b11111111 $ cat hfuse.dat 0b11011111 $ cat lfuse.dat 0b1100010 This is the first AVR I've ever tried to program. I'm guessing I'm making a newbie mistake. And if I need to be directed to a different forum, please tell me. -------------------- matt.c -------------------- /* Gets the avr library from /usr/lib/avr/include on my machine */ #include <avr/io.h> int main (void) { /* PB4/PB3 are not used when programming */ DDRB = _BV(PB4) | _BV(PB3); while (1) { /* PB4 = 1, PB3 = 0 */ PORTB = _BV(PB4); } }

  -------------------- Steps to dupe: -------------------- 1. Using Arduino-0016, program Arduino Duemilanove (Duey) with mega-isp. 2. Hook Duey to Attiny85 (Tiny): Duey Tiny 13 pin7 (PB2 / SCK) 12 pin6 (PB1 / MISO) 11 pin5 (PB0 / MOSI) 10 pin1 (PB5 / Reset) 3. Power Tiny with 5V (independent of Duey) 0V pin4 5V pin8 4. Compile and program Tiny: avr-gcc -mmcu=attiny85 -Wall -I./ -o myblinky.out matt.c avr-objcopy -j .text -O ihex myblinky.out myblinky.hex avrdude -p t85 -c avrisp -b19200 -P /dev/ttyUSB0 avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny85 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.13s avrdude: Device signature = 0x1e930b avrdude: safemode: Fuses OK avrdude done. Thank you. 5. Disconnect Duey from Tiny. Connect reset to VCC. -------------------- Expected output -------------------- I expect 5V on Tiny's PB4 (pin 3) or PB3 (pin 2). -------------------- Actual output -------------------- Tiny: 4.9V pin1 PB5 (reset) 0.4V pin2 PB3 0.3V pin3 PB4 0.0V pin4 GND 0.4V pin5 PB0 (MOSI) 0.4V pin6 PB1 (MISO) 0.4V pin7 PB2 (SCK) 4.9V pin8 VCC Duey: pin7 (heartbeat) LED slowly pulsing pin8 (error) LED never comes on pin9 (programming) LED on while programming, now off -------------------- Other info -------------------- Ubuntu 9.04 $ avrdude -v avrdude: Version 5.5, compiled on Jan 28 2009 at 10:40:52 Here's the fuse data: $ cat efuse.dat 0b11111111 $ cat hfuse.dat 0b11011111 $ cat lfuse.dat 0b1100010 This is the first AVR I've ever tried to program. I'm guessing I'm making a newbie mistake. And if I need to be directed to a different forum, please tell me. -------------------- matt.c -------------------- /* Gets the avr library from /usr/lib/avr/include on my machine */ #include <avr/io.h> int main (void) { /* PB4/PB3 are not used when programming */ DDRB = _BV(PB4) | _BV(PB3); while (1) { /* PB4 = 1, PB3 = 0 */ PORTB = _BV(PB4); } }
• Nov 03, 2009

  issue 12 (Only first byte fails verification) reported by Alastair.Parker   -   What steps will reproduce the problem? 1. Connect attiny45 2. Compile and burn test program using avrdude What is the expected output? What do you see instead? I expected the program to burn and verify successfully (as it does with other chips like the attiny13 and attiny2313). Instead avrdude complains that there is a verification error at offset 0x00. When dumping the flash from avrdude, I notice that the only byte that is incorrect is the first byte. In the case of the attiny45, it seems like the correct byte (19 in this case) is being bit-masked by 0x11 I am also having the same issue with atmega48s (except the bit-mask is 0x25). I have tested my setup successfully with several attiny13 & 2313's. I have also tried multiple attiny45's and atmega48's. turning on -v -v -v -v on avrdude, i notice that avrdude is sending the correct bytes What version of the product are you using? On what operating system? Please provide any additional information below.

  What steps will reproduce the problem? 1. Connect attiny45 2. Compile and burn test program using avrdude What is the expected output? What do you see instead? I expected the program to burn and verify successfully (as it does with other chips like the attiny13 and attiny2313). Instead avrdude complains that there is a verification error at offset 0x00. When dumping the flash from avrdude, I notice that the only byte that is incorrect is the first byte. In the case of the attiny45, it seems like the correct byte (19 in this case) is being bit-masked by 0x11 I am also having the same issue with atmega48s (except the bit-mask is 0x25). I have tested my setup successfully with several attiny13 & 2313's. I have also tried multiple attiny45's and atmega48's. turning on -v -v -v -v on avrdude, i notice that avrdude is sending the correct bytes What version of the product are you using? On what operating system? Please provide any additional information below.
• Sep 29, 2009

  AvrispArduino (User Notes) Wiki page commented on by GeorgeLaskowsky   -   Hi, I am trying to make it work with Arduino-0017 in an Arduino Mega board. I made a simplified shield (but, also tried connecting the micro -mega8515- directly with cables). The only modifications I have done to the program is remaping the pins (but also tried with the same map). I am working on Ubuntu, with the following command I get: {{{ avrdude -p m8515 -P /dev/ttyUSB1 -c avrisp -b 19200 -U lfuse:r:-:i avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding }}} If I dissable heartbeats at code I get {{{ avrdude -p m8515 -P /dev/ttyUSB1 -c avrisp -b 19200 -U lfuse:r:-:i avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check. }}} Sometimes I get other results, but always sync or don't repond problems. What I am doing wrong? Do you need more info to help me? (Forgive me if I am posting these in the wrong place, please delete it) Ah, thanks for your work (I have learn a lot by understanding your code by reading AVR061 and AVR068)

  Hi, I am trying to make it work with Arduino-0017 in an Arduino Mega board. I made a simplified shield (but, also tried connecting the micro -mega8515- directly with cables). The only modifications I have done to the program is remaping the pins (but also tried with the same map). I am working on Ubuntu, with the following command I get: {{{ avrdude -p m8515 -P /dev/ttyUSB1 -c avrisp -b 19200 -U lfuse:r:-:i avrdude: stk500_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding }}} If I dissable heartbeats at code I get {{{ avrdude -p m8515 -P /dev/ttyUSB1 -c avrisp -b 19200 -U lfuse:r:-:i avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: stk500_initialize(): programmer not in sync, resp=0x15 avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check. }}} Sometimes I get other results, but always sync or don't repond problems. What I am doing wrong? Do you need more info to help me? (Forgive me if I am posting these in the wrong place, please delete it) Ah, thanks for your work (I have learn a lot by understanding your code by reading AVR061 and AVR068)
• Jul 28, 2009

  issue 11 (led pin numbers hard-coded in setup()) reported by whosawhatsis   -   Simple fix, the pin numbers for the leds are hard-coded in setup(). They should be changed to used the pin definitions above so that it is possible to use different pin assignments. Change: void setup() { // 19200? Serial.begin(19200); pinMode(7, OUTPUT); pulse(7, 2); pinMode(8, OUTPUT); pulse(8, 2); pinMode(9, OUTPUT); pulse(9, 2); } To: void setup() { // 19200? Serial.begin(19200); pinMode(LED_HB, OUTPUT); pulse(LED_HB, 2); pinMode(LED_ERR, OUTPUT); pulse(LED_ERR, 2); pinMode(LED_PMODE, OUTPUT); pulse(LED_PMODE, 2); }

  Simple fix, the pin numbers for the leds are hard-coded in setup(). They should be changed to used the pin definitions above so that it is possible to use different pin assignments. Change: void setup() { // 19200? Serial.begin(19200); pinMode(7, OUTPUT); pulse(7, 2); pinMode(8, OUTPUT); pulse(8, 2); pinMode(9, OUTPUT); pulse(9, 2); } To: void setup() { // 19200? Serial.begin(19200); pinMode(LED_HB, OUTPUT); pulse(LED_HB, 2); pinMode(LED_ERR, OUTPUT); pulse(LED_ERR, 2); pinMode(LED_PMODE, OUTPUT); pulse(LED_PMODE, 2); }
• Jul 13, 2009

  issue 10 (stk500 not in sync) commented on by drug123   -   Try to add baudrate option: avrdude -c avrisp -P com4 -p t2313 <b>-b 19200</b> Had the same problem, this solved the issue.

  Try to add baudrate option: avrdude -c avrisp -P com4 -p t2313 <b>-b 19200</b> Had the same problem, this solved the issue.
• Jul 01, 2009

  issue 10 (stk500 not in sync) reported by aksoquantor   -   What steps will reproduce the problem? 1. connect an ATtin2313 to arduino 2. press reset button 3. enter avrdude -c avrisp -P com4 -p t2313 What is the expected output? What do you see instead? The programmer seems not to recognize the signature of the t2312. I get the following. Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\UserName>avrdude -c avrisp -P com4 -p t2313 -F avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51 avrdude done. Thank you. ( I should mention I tried several avrdude options) What version of the product are you using? On what operating system? I am using avrisp.03. ( I tested all versions but seem to get the same responses. Please provide any additional information below. When using the option -c avr910 the fllowing appears and keeps repeating. C:\Users\UserName>avrdude -c avr910 -P com4 -p t2313 -F Found programmer: Id = ""; type = ♦ Software Version = . ; Hardware Version = . Programmer supports the following devices: Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) ^C C:\Users\UserName> I also used a 200 ohm resistor between reset and 5V on the Arduino as describe in the Arduino forum but I still get the same result. I appreciate your help.

  What steps will reproduce the problem? 1. connect an ATtin2313 to arduino 2. press reset button 3. enter avrdude -c avrisp -P com4 -p t2313 What is the expected output? What do you see instead? The programmer seems not to recognize the signature of the t2312. I get the following. Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\UserName>avrdude -c avrisp -P com4 -p t2313 -F avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51 avrdude done. Thank you. ( I should mention I tried several avrdude options) What version of the product are you using? On what operating system? I am using avrisp.03. ( I tested all versions but seem to get the same responses. Please provide any additional information below. When using the option -c avr910 the fllowing appears and keeps repeating. C:\Users\UserName>avrdude -c avr910 -P com4 -p t2313 -F Found programmer: Id = ""; type = ♦ Software Version = . ; Hardware Version = . Programmer supports the following devices: Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) Device code: 0xffffffe3 = (unknown) ^C C:\Users\UserName> I also used a 200 ohm resistor between reset and 5V on the Arduino as describe in the Arduino forum but I still get the same result. I appreciate your help.
• Mar 04, 2009

  issue 9 (Have to reload from arduino) reported by wyojustin   -   What steps will reproduce the problem? 1. Load mega-isp from arduino 2. Leave alone for hours/days 3. Come back an try to run What is the expected output? What do you see instead? Expect this: justin@justin-laptop:~/avr/Bikelight$ make /usr/bin/avrdude -p m168 -c avrisp -b 19200 -P /dev/ttyUSB0 -U flash:w:Bikelight.hex -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.11s avrdude: Device signature = 0x1e9406 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "Bikelight.hex" avrdude: input file Bikelight.hex auto detected as Intel Hex avrdude: writing flash (1076 bytes): Writing | ################################################## | 100% 1.33s avrdude: 1076 bytes of flash written avrdude: verifying flash memory against Bikelight.hex: avrdude: load data flash data from input file Bikelight.hex: avrdude: input file Bikelight.hex auto detected as Intel Hex avrdude: input file Bikelight.hex contains 1076 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 1.28s avrdude: verifying ... avrdude: 1076 bytes of flash verified avrdude: reading input file "0xE2" avrdude: writing lfuse (1 bytes): Writing | ################################################## | 100% 0.05s avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory against 0xE2: avrdude: load data lfuse data from input file 0xE2: avrdude: input file 0xE2 contains 1 bytes avrdude: reading on-chip lfuse data: Reading | ################################################## | 100% 0.03s avrdude: verifying ... avrdude: 1 bytes of lfuse verified avrdude: reading input file "0xDF" avrdude: writing hfuse (1 bytes): Writing | ################################################## | 100% 0.05s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xDF: avrdude: load data hfuse data from input file 0xDF: avrdude: input file 0xDF contains 1 bytes avrdude: reading on-chip hfuse data: Reading | ################################################## | 100% 0.05s avrdude: verifying ... avrdude: 1 bytes of hfuse verified avrdude: safemode: Fuses OK avrdude done. Thank you. get this: justin@justin-laptop:~/avr/Bikelight$ make /usr/bin/avrdude -p m168 -c avrisp -b 19200 -P /dev/ttyUSB0 -U flash:w:Bikelight.hex -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.05s avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. make: *** [program] Error 1 The problem is fixed by a reload from arduino What version of the product are you using? On what operating system? arduino: 0010 mega-isp: 03 ubuntu linux: feisty-fawn Please provide any additional information below.

  What steps will reproduce the problem? 1. Load mega-isp from arduino 2. Leave alone for hours/days 3. Come back an try to run What is the expected output? What do you see instead? Expect this: justin@justin-laptop:~/avr/Bikelight$ make /usr/bin/avrdude -p m168 -c avrisp -b 19200 -P /dev/ttyUSB0 -U flash:w:Bikelight.hex -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.11s avrdude: Device signature = 0x1e9406 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "Bikelight.hex" avrdude: input file Bikelight.hex auto detected as Intel Hex avrdude: writing flash (1076 bytes): Writing | ################################################## | 100% 1.33s avrdude: 1076 bytes of flash written avrdude: verifying flash memory against Bikelight.hex: avrdude: load data flash data from input file Bikelight.hex: avrdude: input file Bikelight.hex auto detected as Intel Hex avrdude: input file Bikelight.hex contains 1076 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 1.28s avrdude: verifying ... avrdude: 1076 bytes of flash verified avrdude: reading input file "0xE2" avrdude: writing lfuse (1 bytes): Writing | ################################################## | 100% 0.05s avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory against 0xE2: avrdude: load data lfuse data from input file 0xE2: avrdude: input file 0xE2 contains 1 bytes avrdude: reading on-chip lfuse data: Reading | ################################################## | 100% 0.03s avrdude: verifying ... avrdude: 1 bytes of lfuse verified avrdude: reading input file "0xDF" avrdude: writing hfuse (1 bytes): Writing | ################################################## | 100% 0.05s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xDF: avrdude: load data hfuse data from input file 0xDF: avrdude: input file 0xDF contains 1 bytes avrdude: reading on-chip hfuse data: Reading | ################################################## | 100% 0.05s avrdude: verifying ... avrdude: 1 bytes of hfuse verified avrdude: safemode: Fuses OK avrdude done. Thank you. get this: justin@justin-laptop:~/avr/Bikelight$ make /usr/bin/avrdude -p m168 -c avrisp -b 19200 -P /dev/ttyUSB0 -U flash:w:Bikelight.hex -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.05s avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. make: *** [program] Error 1 The problem is fixed by a reload from arduino What version of the product are you using? On what operating system? arduino: 0010 mega-isp: 03 ubuntu linux: feisty-fawn Please provide any additional information below.
• Feb 25, 2009

  issue 2 (Yikes! invalid device signature) commented on by sv.hoffmann@gmx.de   -   I used the avrdude that comes with WinAvr and that finally worked.

  I used the avrdude that comes with WinAvr and that finally worked.
• Feb 25, 2009

  issue 2 (Yikes! invalid device signature) commented on by sv.hoffm...@gmx.de   -   Hi, I have the samle problem as " EmperorArthur": I programmed the Arudino and connected a 644p to it. The command "avrdude -p 644p -P com3 -c avrisp -b 19200" always returns avrdude: Device signature = 0x1e9406 (which is afaik the ID of the m168 of the arduino) regardles if I connect the 644p or not. I tried to use the avrdude that comes with the arduino 0013 software, but the problem remains the same. Any help is greatly appreciated. Thanks

  Hi, I have the samle problem as " EmperorArthur": I programmed the Arudino and connected a 644p to it. The command "avrdude -p 644p -P com3 -c avrisp -b 19200" always returns avrdude: Device signature = 0x1e9406 (which is afaik the ID of the m168 of the arduino) regardles if I connect the 644p or not. I tried to use the avrdude that comes with the arduino 0013 software, but the problem remains the same. Any help is greatly appreciated. Thanks
• Feb 24, 2009

  issue 2 (Yikes! invalid device signature) commented on by rsbohn   -   It may help to add -v -v -v -v to your command line to avrdude. It will put out a lot more text, but maybe something interesting will show up. Glad to hear that Arduino 13 has an avrdude that works with avrisp sketch.

  It may help to add -v -v -v -v to your command line to avrdude. It will put out a lot more text, but maybe something interesting will show up. Glad to hear that Arduino 13 has an avrdude that works with avrisp sketch.
• Feb 18, 2009

  issue 3 (programming fails) commented on by wyatt.olson   -   I seem to be having a problem programming the fuse bytes as well. Normal flash programming works fine, but reading the fuse bytes always results in 0x00 and writing the fuse bytes fails. I have tried both high and low fuses, with the same results for both. I am on OS X 10.4, using avrdude included with Arduino 013 (I tried the macports version, but it could not even program the flash RAM correctly). I just updated from avrisp 0.2 to 0.3, and the problem exists with both. Output of avrdude (for reading) follows: ./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 -U hfuse:r:-:h -U lfuse:r:-:h avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9406 avrdude: reading hfuse memory: Reading | ################################################## | 100% 0.02s avrdude: writing output file "<stdout>" 0x0 avrdude: reading lfuse memory: Reading | ################################################## | 100% 0.02s avrdude: writing output file "<stdout>" 0x0 avrdude: safemode: Fuses OK avrdude done. Thank you. Output of avrdude for writing follows: ./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 -U hfuse:w:0xdf:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9406 avrdude: reading input file "0xdf" avrdude: writing hfuse (1 bytes): Writing | | 0% 0.00s ***failed; Writing | ################################################## | 100% 0.13s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xdf: avrdude: load data hfuse data from input file 0xdf: avrdude: input file 0xdf contains 1 bytes avrdude: reading on-chip hfuse data: Reading | ################################################## | 100% 0.02s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0000 0xdf != 0x00 avrdude: verification error; content mismatch avrdude: safemode: hfuse changed! Was df, and is now 0 Would you like this fuse to be changed back? [y/n] y avrdude: stk500_recv(): programmer is not responding

  I seem to be having a problem programming the fuse bytes as well. Normal flash programming works fine, but reading the fuse bytes always results in 0x00 and writing the fuse bytes fails. I have tried both high and low fuses, with the same results for both. I am on OS X 10.4, using avrdude included with Arduino 013 (I tried the macports version, but it could not even program the flash RAM correctly). I just updated from avrisp 0.2 to 0.3, and the problem exists with both. Output of avrdude (for reading) follows: ./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 -U hfuse:r:-:h -U lfuse:r:-:h avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9406 avrdude: reading hfuse memory: Reading | ################################################## | 100% 0.02s avrdude: writing output file "<stdout>" 0x0 avrdude: reading lfuse memory: Reading | ################################################## | 100% 0.02s avrdude: writing output file "<stdout>" 0x0 avrdude: safemode: Fuses OK avrdude done. Thank you. Output of avrdude for writing follows: ./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 -U hfuse:w:0xdf:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9406 avrdude: reading input file "0xdf" avrdude: writing hfuse (1 bytes): Writing | | 0% 0.00s ***failed; Writing | ################################################## | 100% 0.13s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xdf: avrdude: load data hfuse data from input file 0xdf: avrdude: input file 0xdf contains 1 bytes avrdude: reading on-chip hfuse data: Reading | ################################################## | 100% 0.02s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0000 0xdf != 0x00 avrdude: verification error; content mismatch avrdude: safemode: hfuse changed! Was df, and is now 0 Would you like this fuse to be changed back? [y/n] y avrdude: stk500_recv(): programmer is not responding
• Feb 18, 2009

  issue 2 (Yikes! invalid device signature) commented on by wyatt.olson   -   Thank you arms22 - it appears that the programming works when using that version of avrdude. The programming finishes and verifies correctly. Not sure about the issue you are seeing. I still have not been able to actually run the program I uploaded, but I think that may be an issue with the fuses being set incorrectly and not using the internal oscillator... more testing should hopefully get this figured out. Cheers

  Thank you arms22 - it appears that the programming works when using that version of avrdude. The programming finishes and verifies correctly. Not sure about the issue you are seeing. I still have not been able to actually run the program I uploaded, but I think that may be an issue with the fuses being set incorrectly and not using the internal oscillator... more testing should hopefully get this figured out. Cheers
• Feb 13, 2009

  issue 2 (Yikes! invalid device signature) commented on by arms22   -   but I have error on next step. $ ./avrdude -c avrisp -p m168 -t -P /dev/cu.usbserial-A60060V5 -b 19200 -C ../etc/avrdude.conf avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9406 avrdude> d efuse >>> d efuse avrdude: stk500_recv(): programmer is not responding

  but I have error on next step. $ ./avrdude -c avrisp -p m168 -t -P /dev/cu.usbserial-A60060V5 -b 19200 -C ../etc/avrdude.conf avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9406 avrdude> d efuse >>> d efuse avrdude: stk500_recv(): programmer is not responding
• Feb 13, 2009

  issue 2 (Yikes! invalid device signature) commented on by arms22   -   It goes well when arduino-0013/hardware/tools/avr/bin/avrdude is used.

  It goes well when arduino-0013/hardware/tools/avr/bin/avrdude is used.
• Feb 11, 2009

  issue 2 (Yikes! invalid device signature) commented on by wyatt.olson   -   I apologize, I am actually on arduino 013 (not that it would make much of a difference in this case). Cheers

  I apologize, I am actually on arduino 013 (not that it would make much of a difference in this case). Cheers
• Feb 11, 2009

  issue 2 (Yikes! invalid device signature) commented on by wyatt.olson   -   Hello, I am experiencing the same issue when trying to program the mega 168. <b>Steps to Reproduce</b> -Upload .pde to arduino master -Connect wires (Master 13 -> 19, 12 -> 18, 11 -> 17, 10 -> 1, GND -> 8 & 22, VCC -> 7) -The heartbeat LED is pulsing on / off; at this time, no other LEDs are lit. -Try to connect with avrdude using command 'avrdude -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200' <b>Observed Output</b> When you run the command, the heartbeat immediately goes out. After about 2.5 seconds, the error LED flashes quickly for about three pulses, then goes off. At this point the heartbeat comes on again. At no point does the programming LED flash. avrdude gives the following output: avrdude -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.05s avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. <b>Versions / OS</b> I am on Mac OS X 10.4, running Arduino 012. I have avrdude compiled from macports, at version 5.5. I am using AVRISP version 0.2. I would greatly appreciate any suggestions on where I may have gone wrong. If you need more information for troubleshooting, please let me know and I will be glad to oblige! Cheers

  Hello, I am experiencing the same issue when trying to program the mega 168. <b>Steps to Reproduce</b> -Upload .pde to arduino master -Connect wires (Master 13 -> 19, 12 -> 18, 11 -> 17, 10 -> 1, GND -> 8 & 22, VCC -> 7) -The heartbeat LED is pulsing on / off; at this time, no other LEDs are lit. -Try to connect with avrdude using command 'avrdude -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200' <b>Observed Output</b> When you run the command, the heartbeat immediately goes out. After about 2.5 seconds, the error LED flashes quickly for about three pulses, then goes off. At this point the heartbeat comes on again. At no point does the programming LED flash. avrdude gives the following output: avrdude -p m168 -P /dev/tty.usbserial-FTE0U36U -c avrisp -b 19200 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.05s avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. <b>Versions / OS</b> I am on Mac OS X 10.4, running Arduino 012. I have avrdude compiled from macports, at version 5.5. I am using AVRISP version 0.2. I would greatly appreciate any suggestions on where I may have gone wrong. If you need more information for troubleshooting, please let me know and I will be glad to oblige! Cheers
• Feb 11, 2009

  issue 8 (Problems writing to EEPROM (Tiny2313)) Status changed by rsbohn   -   Forgot to implement writing to EEPROM. This is now fixed. The hard part was figuring out that avrdude sends word addresses for writing EEPROM!

  Status: Fixed

  Forgot to implement writing to EEPROM. This is now fixed. The hard part was figuring out that avrdude sends word addresses for writing EEPROM!

  Status: Fixed
• Feb 11, 2009

  issue 5 (MOSI and SCK set to output before Reset goes LOW) Status changed by rsbohn   -   Sounds good, changed in the svn and in avrisp.03.zip.

  Status: Fixed

  Sounds good, changed in the svn and in avrisp.03.zip.

  Status: Fixed
• Feb 11, 2009

  avrisp.03.zip (Now can write EEPROM!) file uploaded by rsbohn   -  

  Labels: Featured Type-Source OpSys-All

  Labels: Featured Type-Source OpSys-All
• Feb 11, 2009

  r9 (Implemented writing to EEPROM. Also revised the start_spi() ...) committed by rsbohn   -   Implemented writing to EEPROM. Also revised the start_spi() function.

  Implemented writing to EEPROM. Also revised the start_spi() function.
• Feb 10, 2009

  issue 6 (Some Diecimila Chips are incompatible with this program) Status changed by rsbohn   -   I've also had problems with the Arduino avrdude and recommend using WinAVR.

  Status: Done

  I've also had problems with the Arduino avrdude and recommend using WinAVR.

  Status: Done
• Feb 10, 2009

  issue 3 (programming fails) commented on by rsbohn   -   The avrdude in Arduino 011 doesn't always work. I'd recommend using a current WinAVR toolchain.

  The avrdude in Arduino 011 doesn't always work. I'd recommend using a current WinAVR toolchain.
• Feb 10, 2009

  issue 8 (Problems writing to EEPROM (Tiny2313)) reported by rsbohn   -   Just tried writing the EEPROM from the command line. Failed! Target is a Tiny2313 chip. What steps will reproduce the problem? 1. Create a .eep file using avrasm2.exe (just put some .db stuff in .eseg) 2. avrdude ... -U:eeprom:w:test.eep 3. Seems to write to eeprom but fails validation step. What is the expected output? What do you see instead? Please use labels and text to provide additional information.

  Just tried writing the EEPROM from the command line. Failed! Target is a Tiny2313 chip. What steps will reproduce the problem? 1. Create a .eep file using avrasm2.exe (just put some .db stuff in .eseg) 2. avrdude ... -U:eeprom:w:test.eep 3. Seems to write to eeprom but fails validation step. What is the expected output? What do you see instead? Please use labels and text to provide additional information.
• Nov 10, 2008

  issue 6 (Some Diecimila Chips are incompatible with this program) commented on by EmperorArthur   -   Never Mind. This is only an issue if you are trying to use the avrdude bundled with the Arduino software. Apparently the bootloader is set up so that you use a patched version of avrdude to write to the chip. Using the WinAVR package I didn't have a problem.

  Never Mind. This is only an issue if you are trying to use the avrdude bundled with the Arduino software. Apparently the bootloader is set up so that you use a patched version of avrdude to write to the chip. Using the WinAVR package I didn't have a problem.
• Nov 10, 2008

  issue 6 (Some Diecimila Chips are incompatible with this program) reported by EmperorArthur   -   What steps will reproduce the problem? 1. Attempt to use avrdude with this program What is the expected output? What do you see instead? Expected output: Reading/Writing to the connected AVR Received output: Reading/Writing to the Diecimila's ATMega 168 chip. What version of the product are you using? On what operating system? Arduino diecimila, writing to it with version 0012 alpha on XP Please provide any additional information below.

  What steps will reproduce the problem? 1. Attempt to use avrdude with this program What is the expected output? What do you see instead? Expected output: Reading/Writing to the connected AVR Received output: Reading/Writing to the Diecimila's ATMega 168 chip. What version of the product are you using? On what operating system? Arduino diecimila, writing to it with version 0012 alpha on XP Please provide any additional information below.
• Nov 10, 2008

  issue 2 (Yikes! invalid device signature) commented on by EmperorArthur   -   avrdude -C "..\etc\avrdude.conf" -P com1 -p t85 -c avrisp -b 19200 No matter if there is a chip connected or not it always gives me the ATMega168's signature. When I try to override it to do something like read the first 10 bytes of flash avrdude reports "avrdude: stk500_cmd(): programmer is out of sync"

  avrdude -C "..\etc\avrdude.conf" -P com1 -p t85 -c avrisp -b 19200 No matter if there is a chip connected or not it always gives me the ATMega168's signature. When I try to override it to do something like read the first 10 bytes of flash avrdude reports "avrdude: stk500_cmd(): programmer is out of sync"
• Oct 17, 2008

  issue 5 (MOSI and SCK set to output before Reset goes LOW) reported by wah_...@gmx.net   -   I noticed that in the function "start_pmode()" MOSI and SCK are set to output before RESET is active. That would mean that if the program currently running on the target uC has set the pins corresponding to MOSI and SCK to HIGH, then there would be a very high current (from target AVR to programmer AVR) for a short time. shouldn't reset go active (LOW) first?

  I noticed that in the function "start_pmode()" MOSI and SCK are set to output before RESET is active. That would mean that if the program currently running on the target uC has set the pins corresponding to MOSI and SCK to HIGH, then there would be a very high current (from target AVR to programmer AVR) for a short time. shouldn't reset go active (LOW) first?