Electronics project notes/Avrusb500v2 notes
The Avrusb500v2 is an stk500 V2 compatible AVR programmer
http://tuxgraphics.org/electronics/200705/article07052.shtml
Keep in mind that 'avrusb500' and 'avrusb500 version 2' refer to a board change and are not particularly related to the stk500/stk500v2 distinction.
IO
When you're programming an AVR outside of its target circuit, or in a non-powered board:
- 5V - to power the AVR you're programming, if necessary
- clock output - to provide to AVRs that have fuses set to expect an external oscillator, and the AVR's not in a circuit with one (e.g. when you use)
You need to short one thing to do the initial bit-bang programming. If you don't like the finicky temporary connection, you could e.g. put a male header here to use a jumper.
If you already have an ISP programmer, you can save a bunch of time by using it to program the firmware (there's a row of pins where you can add a header for it).
Before the first use: Programming the programmer
- Preparing/running the tools you need
To avoid the chicken-and-egg problem of having to program the programmer, the board was designed to program its own chip by bit-banging from the FTDI serial chip.
The progam that does this is written for linux's USB interface.
There seems to be a way to use it under windows, but it's easier on linux.
...and probably easiest to use from the bootable tuxgraphics kit's CD, but it doesn't seem to boot for a bunch of people, including me. If it doesn't boot, you probably want to avoid the uisp_bbpg in there. First, it's linked against and old libc++ that you probably don't have anymore, and for me it never worked even when I worked around that: it gave me "ftdibb error: Device not connected". Downloading[1] and compiling a new uisp-patched-with-bbpg fixed that.
When building your own uisp_bbpg:
- depends on libusb-dev, and on a working g++
- uses -Werror in its CXXFLAGS, so it's going to treat every warning as a fatal error.
- See http://letsmakerobots.com/node/18887 for the fixes, OR...
- remove -Werror from src/Makefile.* before you run ./configure
- you'll want to copy the resulting binary somewhere.
- In the avrusb500 package the the bbpg_firmware_load script relies on the path to call uisp_bbpg, so it should be called that (the makefile calls it uisp) and either in the path (or change bbpg_firmware_load to refer to where you have it)
- in the avrusb500v2 package the Makefile calls ./bin/uisp_bbpg, so you'll want to copy it in there
- The programming
Notes:
- Keep in mind that the firmware for the two board revisions don't work for each other, so look out for the difference between avrusb500-x.x.tar.gz and avrusb500v2-x.x.tar.gz. It won't brick, it won't smoke, it will just produce a board that seems to do nothing, and a bunch of confusion in you.
- running uisp_bbpg will unload the ftdi_sio module (visible if you watch syslog), which also removes the /dev/ttyUSB device. This is normal: bitbanging as it is used here needs to talk to the FTDI directly, not as a standard serial port.
- bit banging uploads this way is slow, very slow. Think a few bytes per second, meaning the ~5KB firmware takes ~20 minutes to upload and another ~20 minutes to verify. 'course, you'll only need to do this once.
If you didn't bridge the thing you need to bridge, any attempt to program will complain fairly quickly.
You can try test_1 as a tiny test that'll only take a minute or two to upload-n-check:
make load_test_1
You'll need gcc-avr and avr-libc for it to build.
When the LED blinks, that means that most obvious things that could have gone wrong went fine, so you can upload the actual programmer firmware:
- use make load to make avr-gcc compile the programmer, then have that uploaded, OR:
- use make load_pre to upload the precompiled file (avrusb500_pre.hex) that came with the package
See also:
Using the programmer
Programmer - software
You now have a serial port that speaks stk500v2 (and stk500) so can program things that can speak that.
For example, for avrdude you might use it like: (The m8 in there referring to an Atmega8. Avrdude docs have a list)
avrdude -p m8 -d /dev/ttyS0 -c stk500v2 -e -U flash:w:test.hex
Note that in windows, com ports up to 8 can be specified as com1 to com8, ports above that should be specified like \\.\com12 so e.g.
avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P com8 -U flash:w:test.hex avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P \\.\com12 -U flash:w:test.hex
Reading out the current code:
avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P \\.\com12 -U flash:r:backup.bin:r
Physically connecting the profgrammer