Improve firmware flashing?
ergouser opened this issue · 32 comments
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).
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).
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!
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.
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.
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.
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).
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?
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.
The site used to have instructions on how to use FTDI, but those are gone now. I'd like to see them up again.
@ suranyami, just wanted to followup: were you able to make this work?
Not with the AVRISPMK2, so today I got an Arduino Uno. I'll give that a try this weekend.
A followup on OSX. I finally wrangled a MacBook.
The bad news: Still dont know what's wrong with our instal1.sh script. We chmod it and then execute it; the fuses don't seem to burn.
The good news: We really don't need to burn the fuses. They should already be burned, and unless you'r burning a new chipset, you're fine.
So I'm going to go ahead and do a push with updated OSx scripts in it, for burning updated software.
Don't want to be the guy of the little comments all the time, but on your uno flashing page the osx avrdude link href has the html code for a space in it, which makes my browser interpret the link as a path relative to the current page: http://www.dexterindustries.com/BrickPi/design/brickpi-firmware-update/flash-new-brickpi-firmware-using-an-arduino/%20%20http://www.obdev.at/products/crosspack/index.html
So you might want to take away that space.
two spaces even :) an html code and an actual space. Ah well..
So I finally tried to push the 2.0 firmware to the Brickpi using Arduino. On Linux, OSX and Windows XP. And unfortunately, none of the methods reaped success.
This with the latest changes, and with a working BrickPi. The blue blinkenlight Python test works.
On Windows I got a 'Yikes! invalid device signature' of 0xffffff. I even tried some other arguments to -c. Notably arduino, but all with the same result.
On Linux and OSX I got different results.
First using '-P usb' doesn't work. You have to give the correct path to the /dev/xxx device. Fine.
Then the default argument to -c, avrisp2 gives me a timeout:
avrdude -P /dev/ttyACM0 -c avrisp2 -p m328p avrdude: stk500v2_ReceiveMessage(): timeout
Using avrisp gives me the 'yikes invalid device signature' again.
Using 'arduino' gives me relative success:
avrdude -P /dev/ttyACM0 -c arduino -p m328p avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e950f avrdude: safemode: Fuses OK (H:00, E:00, L:00) avrdude done. Thank you.
However, when I try to give the proper flash commands, it kinda seems to work, takes some seconds to read and write in some instances, but then:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7e00
0x11 != 0x0e
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK (H:00, E:00, L:00)
I had faint hopes of the ic's being flashed anyways, but the check-if-it's-ev3 python program says I'm still on the old firmware.
Linux and OSX gave similar results.
Now I'm officially stuck.
And yes I uploaded the ArduinoISP sketch to the UNO.
@stuij thanks for the heads up about the link. It is now corrected!
You're welcome :)
After a bit more reading and fobbling, I noticed that using 'arduino' will I think just upload code to the arduino :( I feel like such a newbie.
I tried to flash to the BrickPi using the Arduino IDE, and in the process could check how it drives avrdude. Which is basically the same as I've posted. It uses a different programmer-id: stk500v1, but I don't know how significant that is. Still get the same timeout errors: avrdude: stk500_recv(): programmer is not responding
Here's some debugging info if that helps. Same general error for Win XP and OSX:
# /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -patmega328p -cstk500v1 -P/dev/tty.usbmodemfa131 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m
avrdude: Version 5.11, compiled on Sep 2 2011 at 18:52:52
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
User configuration file is "/var/root/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/tty.usbmodemfa131
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATMEGA328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
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 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
And yes, I've got power on the BrickPi when flashing. Although I don't think it's needed. The ISP cable from the UNO is able to power the RPi when it's attached to the BrickPi.
Also this doesn't just happen with fuses. The same thing happens when trying to flash the bootloader.
Did any of you guys get flashing 2.0 to work with a clean stock BrickPi and an UNO on any OS?
So, @DexterInd you said you managed to get hold of a MacBook. Any progress there?
Alternatively: Have you tried using a Raspberry Pi to flash the firmware? Surely this would be a pretty typical use-case?
I've had no luck with the Arduino as an ISP. Uploaded the ISP sketch to it. Connected reset pins & 6-pin header. I run the upload1.sh script and it just says:
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done. Thank you.Which seems to be related to the -P usb port definition.
Does anyone know how to find the USB port address on OSX? I tried running:
system_profiler SPUSBDataTypeAnd it gave me this:
USB 3.0 Hi-Speed Bus:
Host Controller Location: Built-in USB
Host Controller Driver: AppleUSBXHCI
PCI Device ID: 0x9c31
PCI Revision ID: 0x0004
PCI Vendor ID: 0x8086
Bus Number: 0x0a
Communication Device:
Product ID: 0x0043
Vendor ID: 0x2341
Version: 0.01
Serial Number: 75330303035351302161
Speed: Up to 12 Mb/sec
Manufacturer: Arduino (www.arduino.cc)
Location ID: 0x14100000 / 5
Current Available (mA): 500
Current Required (mA): 100
But I have no idea what should be used for the -P param.
Suranyami: it's at /dev/tty.usbmodem[xxx]
There's probably only one tty.usbmodem on your machine; your Arduino. If you want to be absolutely sure, you can install the Arduino IDE, and go to 'Tools -> Serial Port'. It will flag the correct usbmodem as being the Arduino.
My next attempt.
- Connected Arduino Uno via USB.
- Connected 6 pin cable + header as per diagram at: [http://www.dexterindustries.com/BrickPi/design/brickpi-firmware-update/flash-new-brickpi-firmware-using-an-arduino/](Dexter Industries)
- Uploaded ArduinoISP Sketch to Uno.
- Looked at the USB device address in Arduino IDE. It was
/dev/tty.usbmodem1411. - Ran the following:
avrdude -P /dev/tty.usbmodem1411 -c avrisp2 -p m328p -U flash:w:ATmegaBOOT_168_atmega328.hexEnsuring pins are making contact with circuit board, got these results:
avrdude -P /dev/tty.usbmodem1411 -c avrisp2 -p m328p -U flash:w:ATmegaBOOT_168_atmega328.hex
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeoutAlso retried using the Olimex AVRISPMK2, to no avail.
Getting pretty tired of this. Does anyone have a sure-fire way to reflash the firmware? I understand this stuff is not simple, but there should be reproducible steps.
For what it's worth, my AVR ISP looks NOTHING like the one used in the docs.
So, in short:
- the Arduino Uno instructions don't work
- The AVRISPMK2 instructions don't work.
Also, don't you think it might be a good idea to find out how many of your users are Windows, OSX, Linux, Raspbian users?
Maybe I'm in some nutcase minority that should expect compatibility with *nix systems... or maybe not? Personally speaking, apart from the one single firmware developer I know, I don't know anyone that regularly programs on Windows. Perhaps you're a little bit in an echo chamber with all the other Windows/Firmware devs?
At the very least, shouldn't you be thinking in terms of people that only have access to a Raspberry Pi? Isn't that the whole point?
Hey Folks,
I can feel the frustration, and I'm sorry for that. When I saw suranyami's last comment about how we're in an echo chamber with Windows (Seriously? No one uses windows to develop?) we struck on the idea of using the Pi to program. Everyone has one, so it should let us bring the focus down a bit and control the environment.
I've got a new draft worked out that hopefully addresses the issues that stuij brings up. suranyami seems to have a totally different set of issues. I'm going to break them out into two tickets / issues to try to work through them;
We owe a really big apology to stuij because the directions we published for the programmer using the ArduinoISP won't work as we published them. We paid for it in karma having spent a day and change trying to debug the problem.
Firmware Programming with ArduinoISP: #18
Firmware Programming with ISP Programmer: #19
We really appreciate your patience with this and again, we really apologize if we wasted your time earlier.
@suranyami and @stuij , documents for both ways are now up on both pages.
For the Arduino, the key issue was that the programmer cable needed to be slightly modified: the reset line on it needed to be snipped. Hopefully we knocked out the different OS problems and any irregularities by having one script with everything running off the Pi (I think the olimex programmer should work now).