Arduino uno rev3 board came unprogrammed; usb-serial interface malfunctionning?

Hi,

I was recently given a brand new Arduino Uno rev 3 board for tests.
Note that, although I have some experience with a few MCUs (mostly from Microchip), this is my first time with Arduino.

At first, nothing worked at all, I did not even have the ttyACM0 device (I am a linux user) on the computer where the Arduino was plugged. In fact, the device identified itself as "ATmega16u2 DFU". I came to the conclusion that the ATmega16u2 chip came unprogrammed. So I used dfu-programmer to program it with the Arduino-usbserial-atmega16u2-Uno-Rev3.hex firmware I found at

Then I got the ttyACM0 device as expected, and the Arduino Uno board seemed to be seen as expected by the Arduino IDE. But when I try to upload a sketch (the Blink example), it fails with "avrdude: stk500_recv(): programmer is not responding". Investigating a bit, I read somewhere that the L led was supposed to blink a few times on startup, which did not happen. I thought that the atmega328p also came unprogrammed. So I found an AVRISP mkII programmer, to inject the arduino bootloader into the atmega328p chip, with "Tools/Burn Bootloader".

I now get the expected blinking, but I still cannot upload: I still get the same "avrdude: stk500_recv(): programmer is not responding" error.

I tried "Upload Using Programmer", and that works fine: I can upload sketches to the atmega328p through the AVRISP mkII programmer. So its seems to me that the atmega328p part is fine.

I followed the "Loop-Back Test Instructions", but did not get back the characters I typed. I plugged a scope to the loop between pins 0 and 1 and found out that, after the start bit (to logical level 0), only the first five bits (where first means least significant, as standard serial ports are LSB-first) get sent, instead of 8 bits... It looks to me that this would explain why the loopback test fails and why uploading fails.

Looking at the makefile in Arduino/makefile at 6e8e13d7b3679775dae70d9066f05e2f314fe1c1 · arduino/Arduino · GitHub it seems that something should be written to the EEPROM of the atmega16u2 chip, but I could not find that data anywhere. Is that true? Where can I find that data? Can this explain why the usb-serial interface does not work as expected?

Any help is highly welcome.

Your description suggests that the main processor is OK, which is why you can program via the ISP interface, but not the 16U2 processor.

I'm not sure that is the correct file to upload to the USB chip.

Isn't it: Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex

Also make sure the fuses are correct in the 16U2 chip. Mine are:

LFuse = 0xEF 
HFuse = 0xD9 
EFuse = 0xF4 
Lock byte = 0xCF

it seems that something should be written to the EEPROM of the atmega16u2 chip

I haven't heard of that. A quick check of my 16U2 EEPROM shows it not written to (all 0xFF).

100% agree

I first tried the Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex through DFU, but it failed, apparently because DFU could not overwrite itself...
That's why I tried the Arduino-usbserial-atmega16u2-Uno-Rev3.hex one.
Note that, since I could have an AVRISP mkII programmer, I also tried to use it to program the Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex firmware. Programming it went fine, but I still couldn't upload...

Hmmm, good to know.
I programmed the 16U2 processor with:

avrdude -p at90USB162 -F -P usb -c avrispmkii -U flash:w:Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

so it looks like my LFuse and Lock byte were wrong...

I just tried the same command, replacing those values with yours, but then programming the Lock byte fails:

avrdude: writing lock (1 bytes):

Writing |                                                    | 0% 0.00s ***failed;  
Writing | ################################################## | 100% 0.08s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xCF:
avrdude: load data lock data from input file 0xCF:
avrdude: input file 0xCF contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xcf != 0x0f
avrdude: verification error; content mismatch

Do you know whether it matters?
Anyway, uploading a sketch still does not work (same error message)...

That's good to know.

Thanks for your help.

I wouldn't worry about the lock byte.

Now how does the board identify itself?

You probably need to install the correct .inf file (are you using Windows?).

If that all checks out, run the upload in verbose mode (see Preferences) and paste what you see.

Okay

Here's what I get in my kernel log:

usb 3-1: new full speed USB device using ohci_hcd and address 2
usb 3-1: New USB device found, idVendor=2341, idProduct=0043
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
usb 3-1: Manufacturer: Arduino (www.arduino.cc)
usb 3-1: SerialNumber: 749373039363518071D1
usb 3-1: configuration #1 chosen from 1 choice
cdc_acm 3-1:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters

That looks fine to my unexperienced eyes.

I'm no Windows user, I use Debian GNU/Linux.

Here it is:

/usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/build3588799080207223124.tmp/Blink.cpp.hex:i 

avrdude: Version 5.10, compiled on Jun 27 2010 at 00:40:48
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

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

         Using Port                    : /dev/ttyACM0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
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 done.  Thank you.

Nothing useful here, I'm afraid...

Now that you reprogrammed the USB chip can you re-try the loopback test please?

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

I just did it and, unfortunately, it still fails in exactly the same way.
With the "Serial Monitor" in the Arduino software, I see a quare whenever I type one character.
With minicom, I see dots.
And if I connect a DSO to the loop between RX and TX, I see that only the first 5 bits get sent. Hence, "a" and "A'" give exactly the same output...

Can you capture a screenshot of that? Do you get 5 bits and then the line goes back to high? That sounds like a bizarre sort of bug.

Here it is, after I sent a "A" (or perhaps "a", the result is the same) character.
Sorry, the image is a little blurred.
The vertical scale is 2.56/div; the horizontal scale is 256us/div.
The serial port was configured at 9600bit/s, 8 bits of data, no parity bit, 1 bit of stop.

That's it; I confirmed it with all ASCII characters between "@" and "_".

It certainly is.

Hmmm. Can you pull out the Atmega328 chip and then re-run the loopback test?

I just did it, and it did not make any difference. :frowning:

Is this a genuine board? Or a clone? It is starting to look like a problem with the USB chip, but it seems odd to me that a problem manifests itself as discarding 3 high-order bits when doing serial comms.

You can still use the board by programming with the ICSP interface, but of course it looks like sending serial data back to the PC might be an issue. Although it would be interesting to upload, using ICSP, a comms test (like the ASCII chart) and seeing in which direction the problem lies ... sending or receiving.

I'll try reply for z80a (it's quite late in Europe now ^_^), he'll correct me tomorrow if needed... (I try to find the problem with him two days ago with very little success)

As far as we know, it's a genuine Uno rev 3 board (or a very close and unauthorized copy sold as a genuine one)

Same for me...

And it's not very practical either...

It was one of the things we tried, and the output of the example sketch producing an ASCII chart (uploaded by ICSP) was garbled.

OK, well that seems to confirm that it is Arduino -> PC direction that is wrong. Can you check the baud rate of the serial port? eg. with stty

I programmed the 16U2 processor with:
Code:

avrdude -p at90USB162 -F -P usb ...

Can you confirm the USB chip type? You seem to have a at90USB162 (0x1e 0x94 0x82) whereas the Uno has a ATMEGA16U2 (0x1e 0x94 0x89). This doesn't sound quite right.

z80a,

If you do have a 16u2, then you should use -p m16u2. Then you will not need the -F to override the device signature check.

Hi all,

As Koren said, athough I did not buy it myself and I don't know where it was bought, I think it is supposed to be an original Arduino Uno rev 3 board, and as far as I can tell, it looks like on.

I just re-did the ASCIITable test and, as Koren said, the output is still garbled.

I decided to run a simpler test:

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  Serial.write('U');
  delay(1000);
}

The result is that the output is also garbled. I plugged my scope to the TX pin, and the output of the atmega328 chip is correct. More interesting, in arduino's Serial Monitor and minicom, I can see 2 characters every second...

Would it be possible that a broken driver in linux configured the usb-serial interface for 5 bits of data instead of 8? As I understand it, it might explain all failures...

As for the atmega16u2 vs at90USB162 question, my board really has an atmega16u2 chip, and I used avrdude as if it were an at90USB162 to mimic the behaviour of the makefile in Arduino/makefile at 77ed2f4d62d51ca9d79f3353936e9d359d886ccb · arduino/Arduino · GitHub (it uses avrdude to program an atmega8u2 chip as if it were an at90USB82 chip).

I just tried with avrdude -p m16u2 but my version of avrdude does not know this part. I will try a more recent avrdude shortly.

I'm a bit worried when you upload a file for the wrong processor, forcing it to recognize it. Possibly some configuration of the processor (eg. how it handles serial, or indeed, the clock rate) won't agree with your processor. If the clock rate is wrong for the USB chip that might account for the errors you are seeing.

z80a:
I will try a more recent avrdude shortly.

I just compiled avrdude 5.11.1 and used it to reprogram the atmega16u2 chip correctly:

/tmp/avrdude-5.11.1/avrdude -C /tmp/avrdude-5.11.1/avrdude.conf -p m16u2 -e -P usb -c avrispmkii -U flash:w:/tmp/Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex -U lfuse:w:0xEF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0xCF:m

At the end, it makes no difference with my test that outputs a single 'U' character every second.

Can you try on a different PC (eg. Windows, Mac)? That will confirm if it is the board, or maybe the Linux driver.

The most recent Windows license I have is for Windows 98, and the only MacOS I have is for ppc-based macs... I doubt those systems are still supported... :wink:

Anyway, today, I had the opportunity to test this Arduino board on a different PC, running Windows. Good news: it works!

Now, I have to find out why it does not work on my Linux-running computer...

Thanks for your help.