Yun suddenly will not upload sketches

Hi Everyone,

I'm new to working with the Yun and Arduino in general, but not to software development or controls. I was very interested in the Yun as a flexible card we might be able to use on a few jobs that needed something off the normal menu to please a client.

So, I picked a couple up, configured the wifi easily, updated Linino and set to work added sensors. But when I went from basic stuff like talking to a temp humidity sensor on A0, to adding an OLED display form Seeed on I2C, I was unable to upload anything further.

I get this error:

[color=black]Sketch uses 5,132 bytes (17%) of program storage space. Maximum is 28,672 bytes.
Global variables use 153 bytes (5%) of dynamic memory, leaving 2,407 bytes for local variables. Maximum is 2,560 bytes.[/color]
[color=red]***failed;  
avrdude: verification error, first mismatch at byte 0x0000
         0xcb != 0xfb
avrdude: verification error; content mismatch[/color]

And that's trying to load back the "Blink" example or just an empty sketch.

Here's the interesting bit: I can ssh into the Linino side without a problem. It is fully functional as far as I can tell.

I tried to connect the board via usb to burn a new bootloader, but it is not recognised by usb. I thought perhaps I was having usb issues at first, but plugging in anything else, including a Arduino clone called the Xadow, pop right up. The board is just not talking to anyone anymore from the Arduino side.

Is there a way to rebuild the Arduino side of the bridge from Linino?

Is there a way to reset the sketch loaded in the Yun to the default empty sketch either with a button on the board or via Linino?

Any and all advice welcome.

I really don't want to report back to work that the Yun is a board you can brick with a few lines of code, but in my ignorance of how it works it seems I've managed to do so... The scary thing is I was just pulling together example code. It was literally the DHT22 on A0 plus an OLED display on I2C. I also had a Red Bear Labs BLE 4.0 shield on the card, but I was not using it in code. It only uses two pins and they were free.

Relevant links...

BLE shield: http://redbearlab.com/bleshield/

OLED Display: http://www.seeedstudio.com/wiki/Grove_-_OLED_Display_128*64

Temp/Humidity Sensor: http://www.seeedstudio.com/wiki/Grove_-_Temperature_and_Humidity_Sensor_Pro

Kind regards,

-R.

Added note...

I have tried the "hold reset button and upload" trick a billion different ways and it always gives me the same message above. I've tried over ethernet and wifi. I can't over usb because it will not detect the board via usb.

If anyone has even an off-beat idea, please chime in! This board so far is now just a linino sans duino! :roll_eyes:

A Similar Post: http://forum.arduino.cc/index.php?topic=216709.0

Thisn is what I did

http://forum.arduino.cc/index.php?topic=189570.0

It looks like you have triggered this bug:

I haven’t experienced this myself so I can’t swear this will work but give it a try:

  1. Check file that burns the sketch from linino to the 32U4 which is /usr/bin/run-avrdude, it should look like this:
root@Arduino:~# cat /usr/bin/run-avrdude 
#!/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:0xFB:m -Uflash:w:$1:i $2
echo 0 > /sys/class/gpio/gpio21/value

The important part is the “efuse:w:0xFB:m” make sure it is not “efuse:w:0xCB:m”

  1. Check the file the IDE uses to burn the sketch from your host box to the 32U4 which is hardware/arduino/avr/boards.txt which should have a section like this:
yun.bootloader.tool=avrdude
yun.bootloader.low_fuses=0xff
yun.bootloader.high_fuses=0xd8
yun.bootloader.extended_fuses=0xfb
yun.bootloader.file=caterina/Caterina-Yun.hex
yun.bootloader.unlock_bits=0x3F
yun.bootloader.lock_bits=0x2F

Again the important part is the yun.bootloader.extended_fuses=0xfb

  1. Burn a sketch through the WiFi connection which should set the fuses to 0xFB in the 32U4.

What version of the IDE are you using? This should be fixed in the current release.

Yes!!!! That fixes it completely! Everything is back to normal.

Thank you very much!

1. Check file that burns the sketch from linino to the 32U4 which is /usr/bin/run-avrdude, it should look like this:
Code:
root@Arduino:~# cat /usr/bin/run-avrdude 
#!/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:0xFB:m -Uflash:w:$1:i $2
echo 0 > /sys/class/gpio/gpio21/value

The important part is the "efuse:w:0xFB:m" make sure it is not "efuse:w:0xCB:m"

They REALLY need to fix this. It's a small but nasty bug. I seriously doubt anyone new to the Yun would fiddle with this file, much less find it!

Whew! So I didn't waste a hundred bucks after all.

Thanks again to Erni and Noblepepper!

Thanks guys... I'm in the same boat still... (Not a total noob,, BTW)

Updated to Federico's latest full openwrt image. (OpenWrt-Yun 1.0) Updated IDE to 1.5.6.r2

I checked the /usr/bin/run-avrdude.... it is efuse:w:0xFB:m checked:/Applications/Arduino-1.5.6.app/Contents/Resources/Java/hardware/arduino/avr/boards.txt it is: yun.bootloader.extended_fuses=0xfb

Stilll.. Same errors... here is a dump of the AVR prog sequence... ANY SUGGESTIONS WELCOMED AND APPRECIATED.

avrdude: Version 5.11svn, compiled on Apr 11 2014 at 06:11:40
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

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

         Using Port                    : unknown
         Using Programmer              : linuxgpio
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10     8    0 no       1024    8      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : linuxgpio
         Description     : Use the Linux sysfs interface to bitbang GPIO lines

avrdude: Calibrating delay loop... calibrated to 48 cycles per us
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: Calibrating delay loop... calibrated to 47 cycles per us
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
[b][color=red]avrdude: reading input file "0xFB"
avrdude: writing efuse (1 bytes):

Writing |  ***failed;  [/color][/b]
################################################## | 100% 0.06s

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

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

avrdude: verifying ...
[b][color=red]avrdude: verification error, first mismatch at byte 0x0000
         0xcb != 0xfb
avrdude: verification error; content mismatch[/color][/b]

avrdude done.  Thank you.

Ok, both programming methods have 0xFB, this is good. The problem is that the fuse on the chip has 0xCB.

Usually loading a sketch of any kind (maybe use blink?) over the WiFi will set the fuse to the value in run-avrdude script which will make everything agree for you.

Ok, this is very, very bizarre but I think I have traced it down.

Part 1 - How to fix it (don’t do this unless your 32u4 seems “bricked” with the 0xCB bug, read Part 3 for why):
Change the run-avrdude script on linino to read:

#!/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

Yes, you have to set the efuse to the “incorrect” 0xCB value!!! If you ever overwrite run-avrdude, like with sysupgrade, you will need to redo this forever and ever.

Part 2 - How did this happen?
Apparently some Yun’s had 0x3B in the run-avrdude script which really didn’t matter until it was corrected to 0xFB and now the first time it is run it tries to program the board and the first step is to erase the flash, then it checks the fuse and won’t load the program because the fuse value is wrong. Since the entire flash is erased you don’t even have a bootloader to report back to the IDE so it will show up in the port menu.

Part 3 - Why???
This seems to be bugs in both the Atmel chip and in the chip specification for the 32u4 in avrdude.conf.

Atmel bug-
The 32u4 datasheet tells us that the efuse only has 4 bits that matter, so the C or F in 0xCB or 0xFB is irrelevant, only the B matters. 32u4 Fuse Bits.pngThis is fine but I just discovered that you can program (set to 0) the bits in the irrelevant part but you CAN’T UNPROGRAM THEM at least not with avrdude using either linuxgpio or avr109 programmers. They don’t do anything so the only effect is this !@#$%^ problem once they are programmed. Why can you program these bits if you can’t unprogram them, especially if they don’t even matter???
avrdude.conf bug-
This guy says it is a conf file bug but I’m not sure http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=139772&postdays=0&postorder=asc&start=20
Why does avrdue write these in light of the Atmel bug? Yes, avrdude shouldn’t have to deal with someone else’s bug but it really should just always read these bits as 1 and refuse to program them! I am not good enough with avrdude.conf to fix this but here is the section that seems to specify these things, can someone tell me how to fix it??

#------------------------------------------------------------
# ATmega32u4
#------------------------------------------------------------

part
    id               = "m32u4";
    desc             = "ATmega32U4";
    signature        = 0x1e 0x95 0x87;
    has_jtag         = yes;
#    stk500_devcode   = 0xB2;
#    avr910_devcode   = 0x43;
    chip_erase_delay = 9000;
    pagel            = 0xD7;
    bs2              = 0xA0;
    reset            = dedicated;
    pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                       "x x x x  x x x x    x x x x  x x x x";

    chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 0  0 0 0 0",
                       "x x x x  x x x x    x x x x  x x x x";
blah, blah, blah......
blah, blah, blah......

    memory "efuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                          "x x x x  x x x x  x x x x  i i i i";

        read            = "0 1 0 1  0 0 0 0  0 0 0 0  1 0 0 0",
                          "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
      ;

This looks to me like bits 7 to 4 are ignored on write and reported as is on read, maybe the bug is in avrdude’s interpretation of the conf.

Part 4 - Permanent fix (Hey Federico, I would really like a more official opinion on this)
I just tried taking the -U efuse:w:0xCB:m out of run-avrdude and it seems to work fine. I know the intent is to make sure the fuses are right but in light of this problem doesn’t it make sense to just leave efuse alone?
I need a beer at this point, sheesh!!

@noblepepper thank you for opening an issue about the matter https://github.com/arduino/openwrt-yun/issues/12. As said, it looks good to me but I would like a more "core" opinion such as the one of @cmaglie

The efuse value on the linux side has always been FB, it was the java IDE that had the wrong value CB and this was fixed months ago https://github.com/arduino/Arduino/commit/e745ed988fd5f011e444a775ba31b6bb0c3dc4ed

In general, I urge you to check if you're using the latest and greatest version available of all the software we provide: so upgrade your yun if you haven't yet http://arduino.cc/en/Main/Software#toc8 and upgrade your java IDE if you haven't yet http://arduino.cc/en/Main/Software#toc3

In ignorance of it being permanent, I set my Yun’s efuse to CB in avrdude terminal mode in linino. Of course now it will always be CB and I just need to remember to change run-avrdude if I update my image.

Just for my curiosity -

I can not figure out how anyone gets in this situation unless run-avrdude had the wrong value. My arduino IDE doesn’t set the fuses when using USB avrdude -C~/Arduino15/arduino-1.5.6-r2/hardware/tools/avrdude.conf -v -v -v -v -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/tmp/build9127950317095126516.tmp/Blink.cpp.hex:i Did an old version of the IDE set the fuses when using USB?

When using WiFi doesn’t the IDE just use run-avrdude?

The only known way for using the old IDE wrong values is to use an external programmer to flash the yun. There is a old topic in this forum with a user that did just that and ran into the FB/CB problem

I have the same problem and have wasted a lot of time to fix it, trying nearly everything i found it several technical blogs, but nothing works.

This effect takes place when nothing is connected to the YUN and when i am trying to upload an empty sketch.

After wasting 70 Euros and lot of time, i am giving up. I planned to use the YUN in a semi-professional RFID-project, but after this experience, i will have to find another way. It seems, that this problem could "kill" nearly every type of arduino. otherwise i would like to do it with my mega or one of my unos.

I loved my little arduino-zoo and i am very very very frustrated.

MarioLuetkebohle: ::::SNIP::::

@MarioLuetkebohle,

I'm sorry to hear of your problems, but you have posted to a message thread over one year old. DATE is in the top right..

If you would like help fixing your issues, it is likely we can - as that problem was over one year ago.

Please start to a NEW thread and explain your problem - from the start. I'm sure we can help.

Jesse