Hi!
I've got three arduino boards (two Unos, one Nano, all with Atmega328P), on which I couldn't upload code. All of them failed loobback test, and when I had tried to burn bootloader I got this error:
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override this check.
Are they totally broken or is there any way to repair them or check if they still useful?
Thanks for help!
Can't help but boards with the CH340 TTL-to-USB converter will fail the loopback test so for those boards the test is non-conclusive.
Step 5: TROUBLESHOOTING
If anything goes wrong, turn on verbose logging. Go to Preferences... and check the box for "Show verbose output during: [ ] compilation [X] upload"
Error Type 1:
[pre]Reading | Error while burning bootloader.
################################################## | 100% 0.05s
avrdude: Device signature = 0x1eXXXX
avrdude: Expected signature for ATmega328P is 1E 95 0F
Double check chip, or use -F to override this check.[/pre]
That generally means that either you failed to disable the auto-reset on your ISP Arduino or your target processor is not the right type for the Arduino board you selected in Step 4.
Error Type 2:
avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):Writing | ***failed;
################################################## | 100% 0.13savrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:Error while burning bootloader.
Reading | ################################################## | 100% 0.02savrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x3f
avrdude: verification error; content mismatch
That usually means that you failed to disable the auto-reset on your ISP Arduino (see: Step 2). The Arduino bootloader on your ISP Arduino speaks the same protocol as the ArduinoISP sketch. It doesn't, however, allow you to change lock fuse byte and when asked to read that byte it always returns 0x00. If the ISP Arduino resets and happens to have the same model processor as the target (avoiding Error Type 1 above) the first thing to go wrong will be the read-back of the lock fuse byte. Go back to Step 2.
Error Type 3:
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check..
This is a symptom of the target chip's clock not running. That can happen when you are trying to switch a bare ATmega168/328P from a crystal oscillator (like on an Arduino) to the internal 8 MHz RC oscillator. An ATmega that is expecting a crystal needs that crystal to run its system clock. Without the clock you can't burn a bootloader.
There are two ways to provide a system clock:
1: If you can find a crystal between 8 and 20 MHz you can connect it between pins 9 and 10 of the target chip. Do that and try Step 4 again.
2: If you can't find a spare crystal or you try the crystal and still get the "Device signature = 0x000000" error you should get this modified ArduinoISP sketch from adafruit: [iurl=GitHub - adafruit/ArduinoISP: A fork of the ArduinoISP that has 8mhz output clock]https://github.com/adafruit/ArduinoISP[/iurl] Go back to Step 1 and upload this version of ArduinoISP to your ISP Arduino. Connect Pin 9 of the ISP Arduino to pin 9 of the ATmega168/328P on the breadboard. That will provide an 8 MHz clock to allow programming without a crystal.
If you try both methods and it still fails with "Device signature = 0x000000" you might have a chip with configuration fuses set to disable serial programming. To fix the fuses you will need something like the HV Rescue Shield 2 from MightyOhm ([iurl=HV Rescue Shield 2 | MightyOhm]http://mightyohm.com/blog/products/hv-rescue-shield-2-x/[/iurl]). That uses High Voltage Serial Programming to reset your ATmega/ATtiny configuration fuses to factory defaults. If that doesn't work your ATmega/ATtiny is probably damaged beyond use.
Error Type 4:
[pre]avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude done. Thank you.[/pre]
That's no error! That indicates SUCCESS!
No idea why. I did read it once and tested it with Nano clones and they indeed failed the loopback test.
This seems to be the most comprehensive explanation of the cause of false positives from the loopback test on some CH340-based boards:
Additional discussions:
I have personally reproduced this phenomenon on my CH340-based boards.
Two of them (Unos) get Device signature = 0x000000, and I tried burn the bootloader through modified ArduinoISP sketch, but it again gave the same results. Third board gets Device signature = 0xffffff, so I checked all of the connections and tried the same thing, but also didn't work. I will order crystal oscillator and try with it. I guess if that won't work the boards are broken. I wonder how it's possible that all of them gets the same issue.
Anyway,
Thanks for help!
TLDR: the CH340G Nanos drive the Tx and Rx LEDs directly from the Tx and Rx Signals, instead of from separate "traffic indicator" pins (as on FTDI.) The combination of the 1k "isolation" resistors and the 1k "LED Current Limiting" resistors results in a Tx signal that does not meet the voltage requirements for "logic 0" on the Rx pin.
I am especially amused because I tend to use adapters based on the CH340E, which has only 10 pins, and one of them is a "TNOW" "data activity indicator." The CH340G used on many Nano "clones" doesn't have this output, even though it has more pins!
johnwasser, THANKS! I've been working on this problem for a long time. My additional detail for others: If you have a NEW 328P chip that you can't talk to in a barebones fashion (no clock) give it a clock during bootloading or any other fuse setting. If you set fuses to the internal clock, then you can remove the external clock you temporarily added. Bootloading a barebones arduino | MySensors Forum
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.