Uploading to Arduino Yun gives a 'programmer is not responding' error.

[witold-markowski-sentaca]

I'm working with:

• Arduino Yun board
• Arduino IDE 1.6.1
• latest arduino-eclipse-plugin
• development on Ubuntu 14.04 LTS

It fails when uploading the firmware to the Yun via /dev/ttyACM0 serial port:

Starting upload
using arduino loader
Starting reset using 1200bps touch process
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / {} => {}
PORTS { /dev/ttyACM0,} / {} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / {} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
Comport is not behaving as expected
Using comport /dev/ttyACM0 from now onwards
Ending reset using 1200bps touch process


Launching /home/witek/dev/tools/arduino-1.6.1/hardware/tools/avr/bin/avrdude -C/home/witek/dev/tools/arduino-1.6.1/hardware/tools/avr/etc/avrdude.conf -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex:i 
Output:

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
avrdude finished
upload done

Uploading with Android IDE 1.6.1 works fine. After a few debug sessions it looks like the Yun reset function (put it into a bootloader state) fails so the avrdude can not upload the firmware correctly.

I have played with the it.baeyens.arduino.communication.ArduinoSerial.java class and find out that wait_for_com_Port_to_appear method "fails" with the "Comport is not behaving as expected" message. Moreover I see that the Yun board is set to bootloader mode correctly but the wait_for_com_Port_to_appear takes more than 10 seconds to finish.
The default values:

1. int MaxTries = 40; // wait for max 10 seconds as arduino does
2. int delayMs = 250;
   gives exact 10 seconds of wait but the code does more than just waiting, so finally it takes 11.266 after that time the bootloader is off and avrdude is not ablt to connect to.

When I changed the MaxTries back to 20 it worked fine: after 5-6 secodns the wait_for_com_Port_to_appear finished with the default /dev/ttyACM0 port and the Yun bootloader was still active.
When I changed the UPLOAD.WAIT_FOR_UPLOAD_PORT to false it didn't worked as the /dev/ttyACM0 port was not ready yet (?).

This issue is related to #209 when the MaxTries has been increased from 20 to 40. Maybe we could set the MaxTries value to something in between like 30? We can leave that value to 40 but the additional 2000 ms wait time should be defined not only for Digistump DigiX board.
Which is better? Or maybe you have a better solution for that? I can make more tests if needed.

[jantje]

interesting .... very interesting.
Thanks for the research and good documentation of the issue. It is a good example of how it should be.

My 2 cents
I agree that the problem is in wait_for_com_Port_to_appear. However I disagree that playing with MaxTries is a good solution.
The problem is that wait_for_com_Port_to_appear expects the bootloader to come with a "different com port". However from the logging it looks as if in your case you see the bootloader is comming and going with the same com port.
Therefore the wait_for_com_Port_to_appear does not see the port "appear" as it "reappears"
I think following code should fix the issue

int PrefNewPortsCopySize=-10;
do {
....
        /* end of dump to the console */

        // code to capture the case: the com port reappears with a name that was in the original list
            int NewPortsCopySize= NewPorts.size();
            if ( (NewPortsCopy.size()==0) && (NewPortsCopySize == PrefNewPortsCopySize+1)) 
        {
        console.println("Comport appeared and disappeared with same name");
        return defaultComPort;
        }
           PrefNewPortsCopySize=NewPortsCopySize;

        if (NumTries++ > MaxTries) {
        console.println("Comport is not behaving as expected");
        return defaultComPort;
        }

Can you try and create a pull request if it works?

[witold-markowski-sentaca]

@jantje , your fix is working. I have already created a pull request. I'm posting the plugin output for reference:

Starting upload
using arduino loader
Starting reset using 1200bps touch process
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
PORTS { /dev/ttyACM0,} / {} => {}
PORTS { /dev/ttyACM0,} / {} => {}
PORTS { /dev/ttyACM0,} / { /dev/ttyACM0,} => {}
Comport appeared and disappeared with same name
Using comport /dev/ttyACM0 from now onwards
Ending reset using 1200bps touch process


Launching /home/witek/dev/tools/arduino-1.6.1/hardware/tools/avr/bin/avrdude -C/home/witek/dev/tools/arduino-1.6.1/hardware/tools/avr/etc/avrdude.conf -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex:i 
Output:

Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9587
avrdude: reading input file "/home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex"
avrdude: writing flash (4208 bytes):

Writing | ################################################## | 100% 0.32s

avrdude: 4208 bytes of flash written
avrdude: verifying flash memory against /home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex:
avrdude: load data flash data from input file /home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex:
avrdude: input file /home/witek/dev/runtime-EclipseApplication/test2/Release/test2.hex contains 4208 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.03s

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

avrdude done.  Thank you.

avrdude finished
upload done

I can retest the issue after you integrate the fix into your mainline.

[witold-markowski-sentaca]

I'm closing this issue as it is resolved now in the latest (version 2.4.0.201507150213 uploaded from http://www.baeyens.it/eclipse/nightly) build.

[jantje]

thank you very mutch :-)