Arduino Upload Issues


#1

Every time I try to upload to the Cape I get the following error message:

avrdude: stk500_recv(): programmer is not responding

This error causes the reset portion of the script to fail. Any suggestions for how to fix?

Note: I get this error both when uploading through the cockpit and when doing so manually using inotool via ssh


#2

The way folks know to make it work is to yank the chip and put it in a Arduino programmer.

One item to try on the software that *might* increase the odds of success:

try changing the :

/usr/share/arduino/hardware/arduino/board.txt

change the atmega328.upload.speed=57600 to 115200

Also, you can get more detail by editing "

/usr/local/lib/python2.7/dist-packages/ino/commands/upload.py"

and changing the end of the file by adding the -vvv option as:

subprocess.call([
self.e['avrdude'],
'-C', self.e['avrdude.conf'],
'-p', board['build']['mcu'],
'-P', port,
'-c', protocol,
'-b', board['upload']['speed'],
'-D',
'-vvv',
'-U', 'flash:w:%s:i' % self.e['hex_path'],
])


#3

After futzing with this particular issue for quite a while myself, I stumbled upon these articles.

http://blog.stevemarple.co.uk/2012/07/avrarduino-isp-programmer-usi…

http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-av…



Not having any logic converters on hand, I simply ran the avr off 3.3 volts from the RPi and directly connected the necessary pins (probably not a good permanent solution, but it works for now).



Once connected and tested it was as simple as inputting:



sudo avrdude -P gpio -c gpio -p m328p -e -U flash:w:OpenROV.hex


#4

Could you upload exactly which pins you connected where? Also, did you pull the chip out to connect it or leave it in place?
From the poking around I've done, it seems like the only definite success has been using the ISP for upload rather than UART.


#5

I don't actually have a cape. Since the pinout on the Pi is so different from the BB, I decided to build my own cape (crust?).

This is the breadboard layout I have so far. SPI and UART are up and working (just not through OpenROV yet).


Here's the basic schematic I used.


Placing logic converters/buffers in line between the MOSI, MISO, SCLK and GPIO would allow the ATMEGA to be powered by 5v while protecting the Pi.

Keep in mind that you need the patched version of AVRDUDE available from

http://project-downloads.drogon.net/files/

EDIT:

An aside: For UART and clocking, I'm using the configuration available here...

http://shrimping.it/blog/shrimp/shrimp_breadboard_minimal/

Instead of using a UART to USB converter, I'm patching directly into the TXD and RXD pins of the Pi.


#6

I just did a comparison with the cape schematics. The cape already has the pull-up resistor, as well as the extra circuitry on the "minimal shrimp" board. (This just confirms that UART is set up the same way - as we would expect given that it works.) As soon as I can get my hands on a chip puller I'll try this out on mine and test whether uploading this way works fine with the cape. (Other people have had to program by switching the chip into an Arduino Uno; if that worked when put back in the cape, this should too.)

Could you check whether you can upload through UART now that the initial firmware is installed?


#7

Nope...

This is what I got

rov@openrov ~ $ avrdude -P /dev/ttyAMA0 -c arduino -p m328p -e -U flash:w:OpenROV.hex
avrdude: stk500_recv(): programmer is not responding

avrdude done. Thank you.

I know I have all the cables plugged in correctly because I can communicate with the chip over UART. When I launch minicom and short the reset pin to 3.3v, I get the following readout.

vout:109;iout:67;fmem:1346;motors:1500,1500,1500;mtarg:1500,1500,1500;servo:1500;starg:1500;ver:.20130314034900;time:1005

This looks congruent with the output of a correctly loaded sketch...


#8

Hmm, interesting. Maybe the key then is fixing the reset script in avrdude.


#9

Turns out the trouble I was having was from a faulty cape. (I accidentally discovered that all the atmega pins are shorted to ground.) I was able to successfully get UART running on an Arduino Uno board (using the same chip) and will try to upload via that this weekend.


#10

Huh...

I guess that explains why your Raspberry Pi died when you plugged in the servo.

I'd be very interested to see how you make out here. I still haven't been able to get programming over UART to work...


#11

Do you think it would be safe to connect GPIO8 to RESET while the Pi is running off of 3.3v and the ATMEGA is running 5v? I've got SDA, SCL (I2C), RXD, and TXD running off of a 4-channel logic converter so I have no pins left.


#12

I haven't risked it. I either run the atmega at 3.3v or use a relay to keep the voltages separated. From what I've been lead to believe by the internets at large, over-volting the Raspberry Pi shortens its life.