Yun won't work and have tried upgrading.

Hardware Arduino Yún
#1

I bought two Yun's second hand yesterday, one of which works perfectly, but the other won't work and is doing weird things!

I currently have USB, ON, L13 and RX permanently on. I can access the gun via wireless and go through all the configuration panel but the Yun will not show up through USB.

It will not let me upload ANY sketches and comes up with the following issue:

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

/usr/bin/run-avrdude: line 5: can't open /tmp/efuse: no such file
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1

I have completed an upgrade to the latest version via the web panel hoping that would solve it and it seemed to complete ok, I also tried to update via SSH but it failed due to 'broken pipework' ....but I'm still in the same position...can anyone help??

Thanks

Craig

#2

One cause might be that the bootloader on the AVR processor is corrupt or not present. If the Yun's network address shows up on the Arduino IDE Port menu, try uploading a sketch over the network. This will automatically update the bootloader on the AVR chip and might make it work properly?

#3

Thank you Shapeshifter, the Yun does show up on the IDE port menu with the correct IP address, but as soon as I try to upload a sketch it comes up with the error in my previous post…

Is there another way to upload the bootloader on the AVR chip?

#4

A bootloader can be programmed into the AVR chip using the 6 pin header and an ICSP pod. But that's basically what's happening when you program a sketch over the network: the Linux processor adds the bootloader code to your sketch, and then programs the AVR chip using the 6 pin ICSP connection. So I don't think that using an external pod is going to help.

Maybe someone else will be along with a suggestion...

#5

I think the Atmega is broken, because if you can't program it over the network it means that it is not responding at all.

There are other things that make me more convinced about this: the L13 and RX leds always on and the not working USB communication.

Just to try everything you can:
There might be a chance of the presence of a strange sketch that blocks the normal operation of the Atmega so you can try to reset it manually just before the uploading process starts.

#6

Hi, I have the same problem have you solved this with the ICSP?
How can I write the bootloader with a Arduino Uno R3 as ICSP?
Thanks.

#7

Stefano_Baiocco:
Hi, I have the same problem have you solved this with the ICSP?
How can I write the bootloader with a Arduino Uno R3 as ICSP?
Thanks.

ShapeShifter:
A bootloader can be programmed into the AVR chip using the 6 pin header and an ICSP pod. But that's basically what's happening when you program a sketch over the network: the Linux processor adds the bootloader code to your sketch, and then programs the AVR chip using the 6 pin ICSP connection. So I don't think that using an external pod is going to help.

Maybe someone else will be along with a suggestion...

You don't need ICSP flash.

sonnyyu:
You need reflash correct bootloader.

nano /usr/bin/run-avrdude
Change the efuse value from FB to CB

#!/bin/sh

echo 1 > /sys/class/gpio/gpio21/value
avrdude -c linuxgpio -C /etc/avrdude.conf -p m32u4 -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m -Uflash:w:$1:i $2
echo 0 > /sys/class/gpio/gpio21/value




1. flash bootloader only

/usr/bin/run-avrdude    /etc/arduino/Caterina-Yun.hex





2. flash sketch only ( save memory)

/usr/bin/run-avrdude    /tmp/Blink.cpp.hex





3. flash sketch+bootloader

cd /tmp
/usr/bin/merge-sketch-with-bootloader.lua  /tmp/Blink.cpp.hex
/usr/bin/run-avrdude    /tmp/Blink.cpp.hex

You could try:

/usr/bin/run-avrdude    /etc/arduino/Caterina-Yun.hex
#8

Ok sonnyyu, so I must try an ssh connection and write this code:
/usr/bin/run-avrdude /etc/arduino/Caterina-Yun.hex
If this will not function? My 32u4 is damaged and I'll ask for an exchange...?
Thanks.

#9

The working output:

root@Arduino:~# /usr/bin/run-avrdude    /etc/arduino/Caterina-Yun.hex

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9587
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 "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

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

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

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD8"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

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

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

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xCB"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

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

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

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "/etc/arduino/Caterina-Yun.hex"
avrdude: writing flash (32748 bytes):

Writing | ################################################## | 100% 2.57s

avrdude: 32748 bytes of flash written
avrdude: verifying flash memory against /etc/arduino/Caterina-Yun.hex:
avrdude: load data flash data from input file /etc/arduino/Caterina-Yun.hex:
avrdude: input file /etc/arduino/Caterina-Yun.hex contains 32748 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.41s

avrdude: verifying ...
avrdude: 32748 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

root@Arduino:~#
#10

I think there is nothing to do...
AVR device not responding
Initialization failed, rc=-1

#11

Yeeeeeesssssss I did it!!!!!
I have used an Arduino Uno as ISP and rewrited the bootloader on the 32u4!!!
And now L13 blinks!!! : D

#12

Congratulations!

It's curious that running avrdude on the Linux side didn't work while using an Uno as an ICSP did. avrdude on the Linux side should be doing the same thing - programming the MCU using the ICSP pins. Curious...

#13

ShapeShifter:
Congratulations!

It's curious that running avrdude on the Linux side didn't work while using an Uno as an ICSP did. avrdude on the Linux side should be doing the same thing - programming the MCU using the ICSP pins. Curious...

+1

It could be IC U5 related hardware problem. If I were you I will arrange RMA.

#14

Now with the usb port I can program the 32u4, but if I try to program with the wifi, the 32u4 bricks again but load the examples>bridge>wifi status, I can read over wifi and the serial monitor (obviously by changing from serial to console in the setup and so on) the wifi status...

#15

Stefano_Baiocco:
Now with the usb port I can program the 32u4, but if I try to program with the wifi, the 32u4 bricks again but load the examples>bridge>wifi status, I can read over wifi and the serial monitor (obviously by changing from serial to console in the setup and so on) the wifi status...

So it sounds like the USB port on the 32U4 is working (you can program from the IDE using the USB) and the serial port between the 32U4 and AR3391 is working (the bridge communications are working) but loading code from the AR3391 is NOT working (the SPI interface that sonnyyu highlighted in his last post.)

If you had a warranty on the board, I would ask for a replacement. But since you bought them second hand, you likely don't have any warranty on them. If the SPI interface between processors is the only problem, you can work around that by always using the USB interface to load code. You'd be able to do anything that a fully functional Yun can do, except loading code over the network, and trying to use the SPI interface from Linux (a rather advanced and unusual operation.)

#16

ShapeShifter:
...
But since you bought them second hand, you likely don't have any warranty on them
...

begging drop a line to arduino official support engineer, send private message "Angelo9999".

Angelo9999

#17

Know-how is a term for practical knowledge on how to accomplish something, as opposed to "know-what" (facts), "know-why" (science), or "know-who" (communication).

"know-who" is far important than others.

#18

Hi, it's brand new and I had ask for a replacement : ) the seller accepted, so tomorrow morning I'll send back the board : ) thank you lots guys for the help.

#19

After new board arrived and confirm it worked, edit the title of thread as "[SOLVED]" please?

#20