Go Down

Topic: Diecimila: Programmer is not responding (Read 2 times) previous topic - next topic

Jonas

Hi there,

I hope someone could help me out with this, as I'm growing incredibly frustrated. I bought my first Arduino Diecimila yesterday and it worked fine until noon today. I was merrily uploading programs when I got this error:

Code: [Select]

avrdude: stk500_recv(): programmer is not responding


I use Ubuntu 7.10 and as I said, everything worked perfectly at first (I just had to add myself to the "dialout" group in order to get access to the USB device).

Adding upload_verbose=true to the preferences.txt, I get:

Code: [Select]

Binary sketch size: 1114 bytes (of a 14336 byte maximum)
hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168 -cstk500v1 -P/dev/ttyUSB1 -b19200 -D -Uflash:w:/home/jonas/Desktop/arduino-0010/examples/Digital/Blink/applet/Blink.hex:i


avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
        Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

        System wide configuration file is "hardware/tools/avrdude.conf"
        User configuration file is "/home/jonas/.avrduderc"
        User configuration file does not exist or is not a regular file, skipping

        Using Port            : /dev/ttyUSB1
        Using Programmer      : stk500v1
        Overriding Baud Rate  : 19200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding


dmesg outputs these lines maybe ten times:

Code: [Select]

[ 6242.072000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity
[ 6242.072000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate
[ 6242.072000] /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control


I tried it on a Mac and the same thing happens. On an Arduino NG with the ATmega168, the same thing happens. However, an older Arduino with the ATmega8 works!

My Arduino worked as well, though! Please help me before I give up and go back to herding chickens....

Jonas

mem

If the USB serial connection works with another chip then I suspect the bootloader has been corrupted. This has happened on two of my chips (although the averdude error messages were a little different). I think the bootloader can get trashed if a bug in a sketch overwrites the wrong memory area on the chip.

It may be worth knocking together a parallel programmer and reburning the bootloader. That did the trick for me.

Jonas

Argh, I had hoped it wouldn't come to this... thanks though, if that is what it takes I'll throw together a programmer. Anyone have another idea?

Jonas

mem

#3
Feb 02, 2008, 04:16 pm Last Edit: Feb 02, 2008, 04:17 pm by mem Reason: 1
Quote
Argh, I had hoped it wouldn't come to this... thanks though, if that is what it takes I'll throw together a programmer.

Jonas
Making a parallel programmer is a lot easier then herding chickens  ;).

good luck

Adilson Akashi

Did you try pressing reset button instead of waiting for Arduino to Auto-reset?
PCB Designer

mellis

Hmm, what did you have attached to the Arduino before it stopped working?  I'd be surprised if the bootloader got corrupted.  As Adilson said, try hitting the reset button the board before uploading (esp. on the NG, where the timing is easier to get right).  Also, you might try running Arduino as root.

Jonas

Hi guys,

thanks for the pointers. I did try hitting the reset button, the only result was that the flickering of LED 13 stopped while the button was depressed (I'm getting there myself). When I released the button again, it started flickering again.

I tried to throw a parallel programmer together from what I had lying around and it sort of worked. When I say sort of, I mean that I didn't have a parallel plug so I had to stick the cable ends into the plugs on the computer one by one by hand. Messy affair and I don't think it worked too well. I programmed a new ATmega168 and at first avrdude didn't recognize the chip signature for some reason. When I got it the programmer to work at last, it did say "OK" but nothing else happened.

I reached a new phase now, on the original chip and the self-programmed one: when I plug the USB cable into the board, the power light lights up and the RX/TX lights flicker for a short while (a second or so), then they go off. When I press the reset button, nothing happens. When I try to upload something, the RX light flickers softly but nothing else happens. LED 13 stays dead.

I'm also not convinced that the bootloader got corrupted and I can't imagine what I have been doing wrong. I was rigging up three LEDs on the breadboard at the time the Arduino started behaving wonky. The LEDs didn't light up in the order I had programmed. I've been programming for fifteen years and I know I told them to light up one by one (a small extension to the blink program) and they just all lit up at the same time, the loop didn't repeat, stuff like that. And then everything stopped working.

I pretty much gave up on the whole thing by now but I welcome more ideas.

Cheers,

Jonas

mellis

Maybe the bootloader did somehow get corrupted.

Although, does the Arduino NG that you tried (or the Diecimila w/ its original chip) work on any other computers?

Does your computer still work with any of the boards you tried?

(That is, can we tell if the problem is in the computer or the board/chip?)

Jonas

Well, I didn't try to Arduino NG on the other box, but I guess that's the clincher. Since the board didn't work on the other computer (different OS as well), it must be down to the chip or some other component on the Arduino.

I think I'll try to solder a more reliable programmer (with a plug) some time this week and attempt to program the bootloader again. I'll let you know how it works out.

Cheers again,

Jonas

Jonas

I solved it! It ended up being pretty easy, after I soldered my stray cables to a parallel port plug. What happenes was this: the Arduino software never burned the bootloader from the menu because avrdude didn't recognize the signature on the chip for some reason.

I ended up copying the avrdude command out of the Arduino window and adding "-F", which worked fine. What took a long time afterwards is finding out that this first avrdude command just prepares the chip for programming.

Finally I found this thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1187913240/4

There it mentioned the second command needed to program the actual bootloader. Maybe you could put this info at a more visible place, for instance the Bootloader page?

Anyway, I'll finally get back to programming... let's see if I can get something useful out of the Arduino after all.

Later,

Jonas

Jonas

And just in case anyone stumbles over this thread while troubleshooting, I found out what killed my Arduino in the first place. I had written this simple loop:


Code: [Select]
 
// buggy! Don't ever use!
for (int i=startPin;i++;i<=endPin) {
   digitalWrite(i, HIGH);   // sets the LED on
}


That's what happens when you don't stop to think... all you experienced C programmers will laugh at my mistake, I'm sure. As you should. All the others might need pointing out that I switched positions of the condition and the action in the for loop. Every time this loop runs, it increments i and writes HIGH to it. It never stops!

Apparently, digitalWrite doesn't check if the pin number is too high and happily overwrites the bootloader. So, it's back to burning the bootloader for me. Sigh...

Cheers,

Jonas

kg4wsv

Uh, I don't get it.  Program space (flash) is a completely different memory address space than RAM.  Besides that, isn't the bootloader area write protected (with fuse bits)?

-j


Jonas

I thought it was weird as well... maybe it's simply to do with the for loop never ending. Does the bootloader only jump in between repeats of the loop() function? Maybe the bootloader never gets called again since the loop() function never finishes. That would explain why I never got to burn a new program on the chip.

Is there any way to stop the running program and give control back to the bootloader? Pressing the reset button on the Arduino didn't do anything like that on my board.

Jonas

kg4wsv

#13
Feb 17, 2008, 09:06 pm Last Edit: Feb 17, 2008, 09:07 pm by kg4wsv Reason: 1
The bootloader runs once at powerup/after reset.

There is a main() function that does some setup before calling loop() inside an infinite loop.  I've written sketches that don't exit from loop() with no problems that I noticed.

Pushing the reset button should cause the bootloader to run again (once, after the button is released).

-j


Jonas

The buggy program I wrote kept flashing LED 13, but the bootloader never responded. Not even after pressing reset. Maybe my setup function was the problem:

Code: [Select]
// buggy! Don't ever use!
for (int i=startPin;i++;i<=endPin) {
   pinMode(i, OUTPUT);   // sets the LED on
}


Possibly the infinite loop turns an INPUT pin needed for the bootloader into an OUTPUT pin.

Anyway, I don't think it matters much. I found the error and maybe this will help someone else from making the same mistake.

Cheers,

Jonas

Go Up