Uploading arduino firmware


Lights camara but no action yet. When uploading to arduino I get the following error message

Avrdude stk500_rec() programmer is not responding

It will try 10 times then aborts

Then message then reads “upload aborting”

Does anyone have any suggestions



Sometimes it get's a little caught up for random reasons. I'd suggest powering the ROV off, then letting it come back on again, and trying the process one or two more times. It's taken me several times in the past when I have an ROV that is in a bad mood. If that ends up working or if it still gets stuck, please post what happens here- we'll try to get you through it!



Hi Eric

I tried your suggestion with the same results. Seems to be having problems with the syc. I tried installing the new firmware but that didn’t help. When I restarted I didn’t actually take the battery terminals off but simply unplugged the top board. All the LED’s quit flashing so I assumed it was off then I restarted. I also read that it could be a timing issue. Do you have other things I could try.



Hi all

I’m trying to keep this thread alive as I haven’t solved my problem yet. I know that the rest of the world is probably experiencing winter yet so lots of people are not monitoring this forum. We have some great ROVing weather now in the Gulf Islands so I’m anxious to get 778 in the water. I’ve tried rebooting a number of times with no success. I haven’t received my batteries yet so I am using a car battery to power up the control board. Could this be a problem? How any times should I attempt this process before I look for other problems.

Thanks again for any time you can spare for this problem



Hey Dave,

Sorry for the delay in getting back to you. If the voltage of the battery you're using is too low (like below 8v) or if the battery can't source sufficient current, that *could* be the problem, but that seems unlikely to me given your circumstances.

Just to make sure, what version of OpenROV do you have?



Hi Eric

The battery has at least 12V and lots of capacity. I have version 2.6. I am going to check to make sure the BBB is making a good connection to the control board then I will try it again. I noticed one guy solved a similiar problem to mine by changing out the chip, what do you think.




Hmmm... before trying to manually replace the ATMega chip, I'd suggest just sending the board back to us. This way we can get it back to the manufacturer if there's a problem. If you run out of options and want to go this way, please send an email to info@openrov.com and we'll give you all details for how to do that.

Let us know if there are any other things you'd like to try that we might be able to help you out with in the mean time!




I have the same problem. Yesterday I have completed building my kit v2.6 and I have connection with browser, live video stream but that is all. ESCs don't have any power and I can not update Arduino firmware.

Is it possible to use USBasp AVR to update it?



Hi Gregai have just setup my new controller bd and BBB with no issues at all. A few things that I did.

1. I downloaded the image for the BBB and burned it on to the memory card using my Windows system then I put it into the BBB.

2. because I am bench testing and not using the tether I installed jumpers on J17 to provide power to the esc's and J12 for the rest of the electronics.

3. i then connected the BBB to my network and powered it up so that it got an IP address from the DHCP server. I then used a IP Scanner to search my network to find the ip address that was issued to the ROV. Once I had that I used it in Chrome to browse to the Cockpit.

4. Now that the ROV has access to the internet I just went into the diagnostics and did the Arduino Update or download and it worked 1st time.

5. remember in order for the Camera servo to move it has to get it's +5V from the ESC's so they have to have power and be turned on. The Arduino code must also be loaded onto the controller bd done it step 4 above.



after connecting the Arduino board via ICSP Header I think that ATMEGA does not work. I can not even upload a boot-loader.

Here is the error message from Arduino 1.05:

avrdude: error: programm enable: target doesn't answer.

For the OpenROV team:

Do you try to upload the firmware before you send the board to the customer? If not I will try to change the processor.

Kind regards,



I have also tried to upload OpenROV sketch to MultiWii board based on the same ATmega 2650 with the same USBasp programmer and it works. But with the OpenROV Controller v2.6 it does not.


Hi Grega:

Before a Controller Board is shipped out the door, we power it up, flash the bootloader, and install a self-test program which is then run to see if the entire board passes. The flashing D13 and D49 LEDs when you first power-up the board come from the installed self-test program.

Can you describe the symptoms you are seeing with your controller board in more detail? What LEDs are lit on the board?



Hi all

I've just packaged my boards for mail back to openrov repair. Maybe when it arrives this may put some light on the situation.



Hi Walt,

I guess that somehow I damaged the image loaded on BBB. If I use SD card it boots ok. I can SSH and WEB also works.

But when I go to Update arduino the same error:

Avrdude stk500_rec() programmer is not responding

Is there a way to overwrite EE from SD?

About the leds:

TPWR, HP, ETH, PWR and BRX (led4) blinks



here is the output when updating arduino:

undefinedstaging: build dir is /tmp/tmp.mqBmMYz104
staged src in to build folder
Searching for Arduino lib version file (version.txt) ... /usr/share/arduino/lib/version.txt
Detecting Arduino software version ... 1.0.5 (1.0.5)
Scanning dependencies of src
Scanning dependencies of arduino
Scanning dependencies of EEPROM
Scanning dependencies of SPI
Scanning dependencies of Wire
Linking libEEPROM.a
Linking libSPI.a
Linking libWire.a
Linking libarduino.a
Linking firmware.elf
Converting to firmware.hex
Searching for Board description file (boards.txt) ... /usr/share/arduino/hardware/arduino/boards.txt
Searching for Arduino lib version file (version.txt) ... /usr/share/arduino/lib/version.txt
Detecting Arduino software version ... 1.0.5 (1.0.5)
Searching for Arduino core library ... /usr/share/arduino/hardware/arduino/cores/arduino
Searching for Arduino standard libraries ... /usr/share/arduino/libraries
Searching for Arduino variants directory ... /usr/share/arduino/hardware/arduino/variants
Searching for make ... /usr/share/arduino/hardware/tools/avr/bin/make
Searching for avr-gcc ... /usr/share/arduino/hardware/tools/avr/bin/avr-gcc
Searching for avr-g++ ... /usr/share/arduino/hardware/tools/avr/bin/avr-g++
Searching for avr-ar ... /usr/share/arduino/hardware/tools/avr/bin/avr-ar
Searching for avr-objcopy ... /usr/share/arduino/hardware/tools/avr/bin/avr-objcopy
Setting up uploader
Initiating arduino reset on pin 32

avrdude: Version 6.1-svn-20130917, compiled on Dec 6 2013 at 10:44:26
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

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

Using Port : /dev/ttyO1
Using Programmer : arduino
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00


Hi Grega:

Okay, you've provided some good information here.

The first 3 LEDs are for the HomePlug Adapter. The PWR LED means that the Controller Board 5V power is running. BRX means that the Controller is sending telemetry to the BeagleBone (BeagleBone Serial Receive).

So at some point the OpenROV code was downloaded into the Controller Board. I can't say why it is not working now. Perhaps the download was interrupted before it finished?

It seems strange that you cannot access the processor through the ISP port. Make sure that you remove the BeagleBone, have the controller board turned on, and are using an ISP cable that does not try to power the device being programmed. We use this cable.



Hi Grega

This is the same message that I was getting. It gets to a certain point then the message serching for avr which it can't seem to find, then later the Avrdude ... not responding.



Grega and company.

Quick observation. The log shows that the system is detecting the ROV as a cape based rov (because it is using TTY01 instead of SPI to try and upload, we also see that when compiling the .cpp files, it is using cape.cpp instead of contorlerboard25.cpp).

While technically the serial upload should still work it has been a long time since I've used it myself...

If indeed Grega, you have a controlerboard instead of a cape, we really want SPI to be used to upload firmware to the arduino. The only known issue with SPI is that we had an early BETA1 build of the image that was floating around off of a email and forum link that had bugged detection code.

Sorry I've not taken the time time to validate the rest of the thread if this was already answered, but do make sure that if you are using a SD card, that the image is the latest Beta off of the release page on github.



Hey Brian:

Yes, I found the use of TTY01 curious, but if the compile date of AVRDude is in December of 2013, I think this must be a relatively new build. Also, note that the *every* Arduino file is compiled - Cape.cpp, Controllerboard25.cpp, as well as Mini-IMU stuff that is not used anymore. So I don't think you can judge anything from the list of files being compiled.

So does AVRDude fall back to serial upload if the SPI port is not working for some reason?

Grega and Dave:

Can you post here copies of your Arduino AConfig.h file, so we can see that the compiler and programmer are being set up for the new controller board, rather than the old cape?



Good catch on the files loaded. Non the less, the system uses a single detection system and if it is using TTYO1 then it thinks it is running on a cape.

Somewhere around here I have posted the instructions so that you can test the SPI connection and see what it thinks is going on. The only possible failure that is coming to mind would be if the arduino fuses were not set right.

For the blinking LED on the controllerboard, is it blinking 1/second or 1 every 8 seconds?