next topic »

[on:]

(This were some single posts before, I put them together for better understanding)

Hi @ all!
Today I got my arduino-ng board and was quite happy to have it in my hands...
But after some hours with it, I have to admit that it feels like it won't work Sad
 
It tried the Arduino-7 Software under both Windows and Linux, with different delays between pressing reset and trying to write to the device. Tried usb vs. external power. I got a ATmega168 with bootloader too, so I re-seated about 10 times... same results:
"Programmer is not responding."
I even tried AVR-Studio for Windows... The only difference is, that AVR-Studio seems to retry the connection attempt resulting in longer RX activity.
Tried another USB-cable and another computer...
 
But I have never ever seen any TX activity (except after connecting the USB-plug)!!
 
The ATmega8 does one L-led flash after reset, then some seconds nothing and then flashing about 3Hz.
The ATmega168 does 3 flashes, then some time noting, then 3 flashes and so on.
 
----------

>>Hmm... with the ATmega8, does the RX light flash before the L LED starts blinking at 3 HZ?
>> If so, you've got the timing right, as the  bootloader is listening for uploads when the LED is off.  
Yup.
 
>> Can you try setting the upload.verbose flag (in your preferences file) to true and post the output you get?
Sure, but I'd like to do:

Code:

./uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/ttyUSB0 -dspeed=19200
Transmit: { 0 [30]   [20] }
Programmer is not responding.

I get the same output with other baudrates (9600, 2400, 1200) and under Windows and with the atmega168 (of course I set -dpart=atmega168).

With avrdude I get:

Code:

./avrdude -F -p atmega8 -P /dev/ttyUSB0 -c stk500 -b 19200 -vvvv
         avrdude: Version 5.3.1, compiled on Jan 13 2007 at 22:28:39
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/home/jakob/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port            : /dev/ttyUSB0
         Using Programmer      : stk500
         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

As I said, I tried AVR-Studio too. It seems it retries to (re-)send the init sequence of 0x30 0x20 a couple of times, but does get no answer either.
I can even manually send some bytes to it, no response.
(The easiest way is something like echo "0" > /dev/ttyUSB0)

Any comments? Due to the fact more people have the same problem with the arduino-ng, could it possibly be a hardware or design issue?

BTW: I got my arduino-ng from Smart Projects.

[Reply #1 on:]

Hi there,

no solution - I'm just having the exact same problem with my newly received Arduino NG (by PCB Europe).
Read all the previous posts concerning this Problem, tried pretty much every proposed solution/ workaround:

- All Firewalls/ Sync-Software disabled
- Tried different Baud rates
- Checked USB serial port driver (works fine)
- Tried it on different Machines (though both XP with SP2)
- Tried it with different Arduino versions
- Tried different "timing"-Variations (press Reset first, then wait x seconds then upload etc.)

- Power LED lights up
- RX/TX light up very briefly when connecting Arduino NG to USB
- L LED starts flashing/blinking
- Hitting reset
- Hitting "Upload to I/O Board"
- RX flashes *very* briefly
- and here we go:

Still I am always getting that same:

Binary sketch size: 3676 bytes (of a 7168 byte maximum)

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com4 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex


Transmit: { 0 [30]   [20] }
Programmer is not responding.

This is getting slightly frustrating
Anyone any ideas what's going wrong?


Thx,
Moe

[Reply #2 on:]

Hmm.  Maybe the Italian post office has decided they don't like Arduino.

Moe, when you press the reset button, the L LED should flicker briefly, then shut off.  It will remain off for about 6-8 seconds; this is the period during which the bootloader on the ATmega8 is waiting for a new sketch to be uploaded from the computer.  When you're trying to upload a sketch, did you time it so that the RX LED flashes during this period?

Afterwards, the L LED may begin blinking at ~2 HZ or so; this is a test program that was uploaded to the board.  

[Reply #3 on:]

>> Hmm.  Maybe the Italian post office has decided they don't like Arduino.
So what am I supposed to do now?

[Reply #4 on:]

I'd try once more in Linux and Windows.  If it doesn't work, contact PCB-Europe to ask for a replacement.  

[Reply #5 on:]

Thanks for your suggestions, mellis...

However I'm pretty confident I got the timing right.
Started my Computer today, hooked up arduino, tried uploading the
led_blink - sketch.
Produced some long error message concerning Java (stupid me didn't
save it). All I got from then on is the following:
(now during the uploading process RX AND TX flash briefly)

Binary sketch size: 3676 bytes (of a 7168 byte maximum)

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com3 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex


Transmit: { 0 [30]   [20] }
Receive: { . [00] }
Receive: { . [00] }
[VP 1] Device is not responding correctly.

Binary sketch size: 3676 bytes (of a 7168 byte maximum)

E:\Arduino\arduino-0007\tools/avr/bin/uisp -v=4 -dpart=atmega8 -dprog=stk500 -dserial=/dev/com3 -dspeed=19200 --upload if=E:\Arduino\arduino-0007\examples\led_blink\applet\led_blink.hex


Transmit: { 0 [30]   [20] }
Receive: { . [00] }
Receive: { ` [60] }
[VP 1] Device is not responding correctly.

I still can't imagine that it's a problem with the board - i think it's too early for that

Any new suggestions?

thanks,
Moe

[Reply #6 on:]

Actually, it sounds like it is a problem with the board, since the board seems to be sending back the wrong data (and not always the same wrong data either).  You should make sure the ATmega8 is firmly in its socket.  Also, check that there's nothing conductive underneath the board.  Otherwise, maybe the board was damaged in shipping.  Try a few more times and see what outputs you get.

[Reply #7 on:]

Everything back to the good old plain "Programmer not responding".
Tried reseating the AtMega five times without any success, board is not resting on any conductive surface (actually tried different ones - paper, PVC, plastics etc.)

Think i'll get in contact with PCB-Europe and hope for a replacement...

Thanks again for your Help!

Moe

[Reply #8 on:]

fyi you should only have to reseat the Atmega chip once, if at all. The idea is to make sure all its pins are contacting, which generally only takes one try. 98% of the time this is not going to help, it's only for the rare cases where the chip and socket are not aligned.

[Reply #9 on:]

I got my replacement arduino-ng today: It works like a charm!

With the working borad I programmed the serial_hello_world example from http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/ onto a atmega8 and put it in the defective board. I get no TX activity at all...
If I can provide any help with locating the error, just tell me!

[Reply #10 on:]

My replacement Arduino just arrived via UPS - tested it and... it works - finally

Thanks again for providing help!
yours
Moe

[Reply #11 on:]

Unfortunately, the lesson of this thread is: if your "Programmer is not responding", you may simply have bad hardware. I just spent several frustrating hours with three Arduino NG boards that I purchased from some desk at Ars Electronica; after I checked all of the obvious settings (correct microcontroller, correct baud rate, checked the bootloader, bla bla) and tried all of the reset button voodoo (one second before, two seconds after, bla bla), I was still getting this error and I thought I was going crazy. The only solution was to roll back to some very crusty Arduino boards (non-NG) that I had lying around. So watch out, and make sure you get a receipt with your purchases. Not only are there bad specimens, but it seems there might even be bad batches.

[Reply #12 on:]

hey

Massimo will maybe pipe in here, but from experience with hundreds of students using the board,  and what I have heard here in the forum, the rate of bad hardware is really miniscule...  

What version of the board is it that you bought at Ars? If you have one of  'crusty' board working, you can swap the chip with the NG board and try that to verify if indeed there is a hardware problem.

  

D

[Reply #13 on:]

 :-[ Well, after I tried everything in the troubleshooting guide, I learned that it was "human error" after all. It seems that I simply had not tried the right combination of voodoo for downloading the program to the board. In my case, I did actually experience some behaviour that I had not seen described before:

I had to press the Reset Button AFTER I pressed "Upload to I/O Board". And when I say AFTER, I mean 4 to 5 seconds after. Seriously. Of course, this is the opposite advice from the feedback returned by the Arduino IDE....

It also turns out that (in my case anyway) there is a very narrow window of time where the Uploader will work. If I press the button too early, "Programmer is not Responding". If I press it too late, "Programmer is not responding". I have less than a second's time to get it right.

So, I hereby apologize to Massimo and the Crew for impugning the hardware -- typical newbie nonsense, I'm sorry. But I have to say, it would be great if there were a "Ready to receive program" indicator on the Arduino board, so that I wouldn't have to guess when to jump into the void.

Regards,
Golan

[Reply #14 on:]

The problem's with the Arduino software, not the board...  That is, there's already a ready to receive signal - an LED on pin 13 flashes three times when the bootloader starts, after which you have 5-6 seconds for the upload to begin.  For simplicity, however, the Arduino environment recompiles your code every time you upload (I want to do something about this, but it's not been the highest priority), which on some machines seems to be very slow for reasons I don't really understand.  Thus, by the time the upload begins, the bootloader has already timed out.  

The suggestion of pressing the reset button after the hitting upload is mentioned on the troubleshooting page http://www.arduino.cc/en/Guide/Troubleshooting, but it's certainly easy to miss.  I'll take a look at improving the error message in the environment.