Improve firmware flashing?

[ergouser]

Not really a request for an enhancement, more a discussion starter.

I think this should be fairly easy and work well.

If you put a serial bootloader on the atmel processors on the board and put two reset switches connected to a Pi pin a (very slightly) modified version of avrdude should be able to start, wait until the Pi pin is high and so one of the atmels has reset and then download new firmware over the serial link.

Might need to be a little cleverer, like hold the other Atmel in reset while you flash the other one, but I doubt it. Might also be possible to reset both chips and flash both at the same time (but I think that would be much more complex).

[suranyami]

Can we also get some better documentation on how to do this?

I've got EV3 sensors I'd like to try, and an AVRISPMk2, but I can't see in the docs what the steps would be to flash the new firmware. That said, I've not done this kind of thing before.

Which .hex files do I need to download?
What are the params to avrdude?
I'm using linux or OSX. What are the steps there?

I'm happy to write this up in a fork of this repo, but it'd be good to have some starting points.

Thanks in advance.

David,
We're on this. It's on our list to improve the documentation on how to
upload the files with either an AVRISP or an Arduino.

On 6/19/2014 5:10 PM, David Parry wrote:

Can we also get some better documentation on how to do this?

I've got EV3 sensors I'd like to try, and an AVRISPMk2, but I can't
see in the docs what the steps would be to flash the new firmware.
That said, I've not done this kind of thing before.

Which .hex files do I need to download?
What are the params to avrdude?
I'm using linux or OSX. What are the steps there?

I'm happy to write this up in a fork of this repo, but it'd be good to
have some starting points.

Thanks in advance.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[suranyami]

Thanks. If you just have brief notes, I can attempt to reproduce the steps and write them up as proper documentation.

We've spent some time today reorganizing the BrickPi site. Here are three pages:
An intro to the firmware update ( http://www.dexterindustries.com/BrickPi/design/brickpi-firmware-update/ )

Using an Arduino. (http://www.dexterindustries.com/BrickPi/design/brickpi-firmware-update/flash-new-brickpi-firmware-using-an-arduino/ )

Using an AVR Programmer. (http://www.dexterindustries.com/BrickPi/design/brickpi-firmware-update/flash-new-brickpi-firmware-using-an-avr-programmer/)

Any feedback on this would be awesome. Thanks!

[stuij]

Very awesome!!

Ok a few notes :) :

• I think the ribbon cable you linked to is wrong. Or if it's not, it's confusing. That ribbon cable is a 10 pin to 6 pin. However it's supposed to slide around the 6 pins on the Uno, and on the 6 pins on the Brickpi. At the top of the page it says that it supports both 10 and 6 pin interfaces, but you can see the weird wiring, which doesn't match your tutorial picture, combined with this site comment:

  "I wish I read blink4jona’s comment before buying as what I received is not what I expected. The cable can connect ISP 10-pin to 10-pin, 10-pin to 6-pin, but not 6-pin to 6-pin (there is only a single 6-pin connector).
  The description is misleading as it suggests both 10-pin and 6-pin ISP interfaces are supported. Also you can not tell from the picture that only a single 6-pin connector is included.
  Although it may be useful to some, we need a no fuzz 6-pin to 6-pin alternative."

  This one seems to be right: https://www.adafruit.com/products/371

• There's just mention of the windows script procedure, no Linux/OS X, even though they're mentioned briefly at the top of the howto. In this howto scenario, users usually want to be taken by the hand I think, as they might be in a bit over their head with foreign technology. I would at least mention the upload1.sh and upload2.sh scripts in the repo, and change the start of the com port search section from "Find and note the COM port..", to "For Windows, find and note the COM port..", so as to avoid confusion.

• The upload1.sh and upload2.sh scripts in

  BrickPi / Firmware_BrickPi / Updating_the_Firmware / Firmware_2.0_Loading_Package /

  are not actually bash scripts. You might want to prepend them with

  #!/bin/bash

But thanks a lot :) Flashing the firmware is so much clearer now.

[stuij]

Oh and on the Arduino flash page the pics at point 5 and 7 aren't clickable, while especially those are nice to click just to get a closer look of the cabling. They used to be clickable on the old howto. Also the pic of point 3 of the AVR programmer page.

[stuij]

Last bit: there's no info on the 2x3 header in the uno documentation. I would copy that over from the avr section. And lastly: It's ok that the jumper wire just sorta hangs in the appropriate reset hole? What happens if it would slip out because of movement while flashing? This was my last comment, I swear! (for now..)

stuij, thanks so much for all the comments and help.

• Great point about the ribbon cable. We changed it.
• Easy win on the pictures. I've gone through and they should all be clickable now. Caught some on the AVR Programmer page.
• Added in a 2X3 header on the uno documenation.
• Jumper wire: We'll try to make it more explicit: for the duration of the progamming, you have to hold it to the side so it exerts pressure on the inside of the hole and makes contact. I've made a quick change there.

The mention of Linux and mac: we can get directions up that show how to use it as well. We've got an ubuntu machine we can try it out on. We can find a mac machine before the week's end.

[ergouser]

I'd still advocate flashing a serial bootloader. I think it should then be possible to flash the chips from the PI using AVRDUDE and a single jumper to reset one of the chips (maybe need to hold the one you're not flashing in reset so that it doesn't get confused and start talking on the serial link). The ISP would then be unnecessary (after flashing the bootloader).

It would be possible to automate that on a future BrickPI design (pull the resets to I/O lines and modify AVRDUDE to control those lines - or just make resetting the ATMELs convenient and save the I/O).

[suranyami]

I'm using an Olimex AVR-ISP-MK2 on OSX and Ubuntu. I get the following errors when running the upload1.sh scripts on both machines:

avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port

If I try running one of the avrdude commands with verbose output I get:

$ avrdude -P usb -c avrisp2 -p m328p -U lfuse:w:0xFF:m -v

avrdude: Version 6.1, compiled on Mar 23 2014 at 04:42:55
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/usr/local/Cellar/avrdude/6.1/etc/avrdude.conf"
         User configuration file is "/Users/djp/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200012345
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -5 out of 1 bytes, err = Input/output error
avrdude: stk500_send_mk2(): failed to send command to serial port

Results are the same on both machines.

I've tried different USB cables, just to make sure that wasn't influencing the results.

Some questions:

• PDI interface or TPI?
• I've disconnected the BrickPi from the Raspberry Pi, and it's not powered. Is this right?

ergrouser: yes, actually the hardware will lend itself pretty well to this. However . . . there's no Arduino bootloader on the chips, so programming has to be done via an ISP programmer. HOWEVER, the solution we're testing right now will be to publish a firmware hex file that has the Arduino bootloader incorporated.

@suranyami This might be a little hard for us to troubleshoot, we don't have an Olimex on hand. I'll try to do a little research on the error code you're getting back.

However! You definitely should be powering the BrickPi. You can connect it to the Raspberry Pi, and power it that way (very low power consumption process this is), or you can hook up a 9V battery source.

RE: PDI vs TPI I think this are programming protocols, and the Atmega328 uses neither as far as I know. Is there an ISP option?

Just poking around on the AVR website, the mk2, "This tool is used for field upgrades of Atmel 8-bit AVR microcontrollers with ISP or PDI interfaces. Using the included AVR Studio® software, designers can program tinyAVR and megaAVR devices using the ISP Interface, tinyAVR devices using the TPI interface, and AVR XMEGA devices using the PDI Interface."

So you'll want to use an ISP programmer option.

Anyone else tried this yet? Should we close the ticket?

[suranyami]

I made a bit of progress on this.

The Olimex documentation says that in order to work with avrdude, the firmware on the AVRISPMK2 needs to be updated also. So, I need to update the firmware to update the firmware.

I managed to get the AVRISPMK2 updated, and it now responds sensibly to avrdude commands.

I then tried updating the firmware on the BrickPi, but had a whole different set of errors. When I get back home, I'll try again, and put them up here.