ATtiny167 Bug with AVR Extended Commands?

I was advised that there’s a bug in my AVRDUDE code for the ATtiny167.  I don’t have a 167 to test it for myself as yet, so I’ll have to get hold of one, which may take a while.  In the meantime, if you’re using a 167 and you get strange errors, attached this to the end of your AVRDUDE command line;

-x nopagedread

That extended option will disable my update temporarily.  I’ll check it out when I can get hold of one and update patches if required.  This may take some time.

EDIT:  Ouch.  Both Mouser and Digikey want over 30 dollars to ship a $2.50 part.  Postage to Australia really sucks.  If anyone’s got one and wants to send it to me, let me know and I’ll Paypal you for it.


BusPirate AVRDude Patch Updated!

EDIT:  Patch updated again to remove the last of the warnings.  Also incorporated a fix to the progress bar and one to only put up the raw paged_load commands on verbosity > 1 – thanks to Nils Steinger for the fix!

EDIT:  Patch has now been integrated into the official AVRDude SVN as per revision 1137 !  This means that any nightly builds of AVRDUDE should have the functionality built in, and the next release will have it!  

At the request of a reader, I’ve gone and updated the avrdude patch I wrote for the BusPirate to work with the latest SVN of AVRDUDE (release 1132 at this time).

A few changes were necessary, and notably the paged_load method is now slightly different.  At any rate, I’ve updated the versions of the files you can find in my GoogleCode Repository at this link to work.  The new is built from the latest SVN.

Notably, this was also built against the latest version of libusb-win32.

In order to test, the easiest thing to do is to grab the optiboot firmware for your Arduino out of the Arduino install (look for optiboot_atmega328.hex), then write it like this;

avrdude -v -p m328p -P COM4 -C avrdude.conf -c buspirate -U flash:w:optiboot_atmega328.hex

Verification of the bootloader takes 0.89 seconds.  Obviously substitude atmega328 with whatever type of ATmega you have, and substitute the COM4 for your serial port your BusPirate is attached to.

The command to dump the existing flash to a file is;

avrdude -v -p m328p -P COM4 -C avrdude.conf -c buspirate -U flash:r:firmware.hex:i

Full 32k flash verification takes 40.90 seconds. This should work fine with a 2560, although I haven’t as yet had a chance to test.  Getting this updated patch out was a rush job to make it available.  I’ll test with the 2560 before reposting to the AVRDUDE Developers.

Custom Firmware on F-30 ESCs

I just got my new Hobbyking F-30 ESCs for the new quad I’m building.  Now, I specifically picked these ESCs because they are a great candidate for using the SimonK ESC firmware on.  This firmware is custom-written to be suitable for multicopters, and has far superior response characteristics to standard firmware.  The F-30 has a few features which make it a good pick (I think) for this firmware;

  • It has an Atmel processor, and there’s no signs that will be stopping.  The Plush series changed over to a Silicon Labs processor recently, so all new ones will be SiLabs
  • Overpowered for what I need, but it only runs 2 grams heavier than the F-20
  • Has an external oscillator
  • Has programming pads and they’re in a row and quite accessible

You can find a database of supported ESCs and notes about them at the RapidESC Database.  At any rate, I went and cut open my F-30’s, stripped off the heatsink, and what I found was basically exactly what I found at the RCGroups thread about it;

HK F-30 ESC (pic courtesy

Fantastic!  So, I went ahead and made up a jig for connecting to the pads using some single-strand copper wire, a hot glue gun, and a clothespeg;

Programming jig – highly professional

As for programming, I wired it all up to my BusPirate, and then ran the following command;

avrdude -c buspirate -P COM8 -p m8 -v -U flash:w:bs_nfet.hex

The .HEX file can be got from the Downloads link at SimonK’s GitHub site.  It was rather fiddly getting all six pads touching at once, but once I got into the swing of it, I got all six programmed fairly quickly.

Then for testing.  For testing, I used a bunch of leads with alligator clips on them, hooked up the ESC to a spare Turnigy 2217-16 motor I have lying around (no propeller!), and then connected the power to a benchtop power supply I’ve got.  I used the benchtop supply because it can’t put out too much current, has short circuit protection, and has an adjustable voltage output (I used 8 volts).  Hook up the ESC servo cable to channel 3 on a cheap receiver, and hold onto your hat.

They all worked.  First power up was with the transmitter off, and the ESC beeped three times (ascending) as expected.  Second power up was with the throttle on maximum.  Three beeps, followed by one extra beep.  Drop throttle to minimum, ESC emits two beeps.  From there, moving the throttle makes the motor fire up and do what you’d expect.  There’s a notable lack of strange clicking sounds like you get with the stock firmware.

Next up is to repeat the same thing on my older Turnigy Plush 25A ESCs, but first I need some heatshrink that I can put on all the ESCs to protect them.  I’m quite looking forward to seeing how the existing quad flies with this new firmware in place.

Bus Pirate Extended Commands works with ATmega2560!

I finally got an ATmega2560, and therefore went and updated my Bus Pirate extensions to support memory paging on it.  The fix wasn’t too extensive, just a matter of having some hardware on hand to test it.

I have also gone and updated all the avrdude and buspirate patches to support the latest versions of both (avrdude 5.11 and buspirate 6.1 r1676).

The details can be found in my original blog post about this at

If you use it, let me know how you go!

Bus Pirate & AVRDUDE Revisited

It’s been a while.  I’ve revisited the AVRDUDE patches I made to the Bus Pirate to make sure everything actually works with the version 5.11 AVRDUDE that comes with the Arduino 1.0 IDE.  I’ll also be gradually updating all my GoogleCode stuff to make sure that it works with the Arduino 1.0 IDE.

The current avrdude patch I wrote still works with the 5.11 AVRDUDE.

AeroQuad 2.5.1 – Code Upload via ICSP

So I’ve been fooling with the new AeroQuad 2.5.1 code, and I’ve integrated some fixes posted by Kenny9999 (an forum user), as well as integrated my battery level compensation code.  Unfortunately though, putting in both makes the code a little too big to fit into the 32256 bytes you have available on the Uno with the Optiboot bootloader.

Since I have an ICSP programmer (Bus Pirate to the rescue!) I decided I’d go and upload the code directly.  That way I can utilize the entirety of the flash!

As discussed in my post about using a Bus Pirate as an ICSP programmer, you need to set up a new hardware definition for Arduino.  Mine’s called tiny45_85, but we’ll use that for a new ATmega328p definition.

Edit boards.txt in tiny45_85, and add the following; 16MHz (w/ BusPirate)

Essentially what this does is create a new entry in the Arduino IDE’s “Boards” menu, which will upload using the Bus Pirate programmer definition we made in attiny45_85/programmers.txt, setting the maximum upload size to 32760 bytes at 16MHz.  It will use the build core for a normal Arduino.

What’s notable is that the default fuse setup for an Arduino (here) will set the high fuse to 0xD6.  This sets up the Arduino so on boot it will boot the bootloader.  In other words, code execution will not begin at address 0x0000.  This won’t work if you have no bootloader.  The fuses need to be changed so that the BOOTRST flag is unprogrammed.  In AVR-speak, this means it’s set to a value of 1 (0 means “programmed).  So, this means that the high fuse needs to be set to 0xD7.  No other fuses need to be changed.

To change this, you’ll need to run AVRDUDE with a command line like this;

avrdude -p m328p -c buspirate -P COM8 -v -C ..\etc\avrdude.conf -U lfuse:w:0xFF:m -U hfuse:w:0xD7:m -U efuse:w:0x05:m

Once I figure out exactly how to do it through the IDE, I’ll integrate that into boards.txt above and edit this post.  If you don’t change that fuse, your code might work, since the flash will by default be filled up with 0xFF’s, but if your code happens to be big enough to go into where the boot is trying to start, it probably won’t work.  Set the fuses right.

After that’s all done, you should be able to fire up your Arduino IDE, and see a new entry in Boards called “ATmega328p 16MHz (w/ BusPirate)”.  Select that as the target board, upload and voila!  Your code will be burned directly onto the ATmega328p with no bootloader through ICSP.

I’d suggest that you use the bootloader (since then you can use the built in USB upload) unless you have specific reasons not to (eg, pin state on boot causes the bootloader to lock up, or you need the space).

Bus Pirate – 40x Verify Speed Increase!

Update 19th April 2012 – I finally go an ATmega2560, so I fixed the code to work with memory paging and also updated the patches to work with all the latest versions of AVRDUDE and the Bus Pirate firmware.
Update 12th January 2013 – Haven’t touched this stuff in a while, but a reader informed me that the patch no longer works with the latest SVN.  I’ve updated it to work with the latest SVN (release 1132 as of this writing).

Been messing about for the past day in trying to increase the speed of the Bus Pirate when acting as an ICSP programmer.  Basically, I didn’t like the idea of waiting 15 minutes+ for a 32k flash to verify.

I did some examination of just how the BP works with AVRDUDE, and in the process learned a gory amount about SPI, binary bitbang on the Bus Pirate, and how to use SPI to talk to an Atmel MCU.

It turns out that the reason why the BP is so slow during the verify step is that it handles the whole SPI transaction through the UART, so it’s sending/receiving up to 13 or so bytes per one byte that is coming out of the flash, and that’s happening in multiple distinct synchronous transactions.  So there’s a huge amount of delay, and that adds up to very slow performance.

The solution I had to this was to try and move the SPI transaction stuff directly onto the Bus Pirate.  First I coded up some stuff to use the BASIC scripting engine to run the SPI transactions.  It worked, but it was a little messy.  The final solution was to customize the firmware on the Bus Pirate to add a new set of commands in SPI bitbang mode, and then customize avrdude to detect the availability of those commands and make use of them.

Now it only takes ~30 seconds to verify a 32k flash, which is up to a 40x speed increase!  Read on for how to do it.

The Bus Pirate Firmware

Working from the 6.1 firmware, I customized it to include some new commands in SPI bitbang mode.  Specifically, sending a 0x06 enters what I’ve termed “AVR Extended Commands” mode, which currently only has three subcommands;

  • 0x00 – Do nothing
  • 0x01 – Report the version of the AVR Extended Commands module, returns a 2-byte unsigned, MSB first.
  • 0x02 – AVR Bulk Memory Read, following 4 bytes (MSB first) is the starting offset where memory should be read (IN WORDS), following 4 bytes is the number of bytes to read.  returns a 0x01 for success and the data.

When you compile firmware with MPlab for the Bus Pirate, you need to do a Build All, and then export the .HEX using program addresses 0 through to 0xA7FF, and don’t export configuration bits.  That will give you a .HEX that is useable and won’t overwrite the bootloader.

For those who don’t want to build their own, a pre-compiled firmware image is above.  Install it using the DS30 Loader like you would any other Bus Pirate firmware.

AVRDude Customizations

Tim Vaughan has submitted a patch for inclusion into AVRDude which dramatically improves performance with several tasks as well as making AVRDude actually work with 6.1 Bus Pirate firmware.  I’ve used that patch, and then included enhancements by myself to implement the paged_load() method using the AVR Extended Commands in the Bus Pirate firmware.

You can disable the use of the new paged load method with the “nopagedread” extended parameter to avrdude.

When avrdude initializes, it will probe the Bus Pirate to discover whether it has the AVR Extended Commands installed.  If not, then no harm will be done (0x06 does nothing by default), and avrdude will carry on as it would normally.  If it is found, then the Extended Commands will be leveraged to greatly speed up flash read operations.

Bus Pirate as ICSP Programmer

NOTE:  This article was written for the Arduino 022 IDE, not for the release 1.0.  Things are now quite a lot simpler in the 1.0 IDE, so this article will be getting a severe editing once I get to retest everything.  Stay tuned.

As discussed in my last post, I got a Bus Pirate yesterday.  One of the first things I wanted to do with it was use it as an ICSP programmer for an ATtiny85.  The ATtiny85 is an 8-pin microcontroller with (up to) 6 I/O lines and 4 ADC’s.  It can run up to 20MHz with an external crystal or 8MHz with its own internal oscillator.  It has 8k of flash available.

In this post, we’ll discuss hooking it up to the Bus Pirate, getting the BP talking to Avrdude, setting up the efuses to use the internal oscillator, and then configuring the Arduino IDE so you can upload to it through the BP.

Caution:  The BusPirate is really really slow as an ICSP programmer.  It’ll work, but it may take 15 minutes to write and verify the default bootloader on an ATmega328p due to the large flash size.  On an ATmega2650 it might take an hour.  Be patient.  Or use the customized AVRDUDE and BP firmware I discuss here.

Step 1 – Connecting the BP to the ATtiny85


As it turned out, hooking up the BP to the ATtiny is pretty easy.  Just follow the pinouts on the Microcontroller Cheat Sheet;

Microcontroller Cheat Sheet (link above)

Pay particular attention to the fact that the BusPirate I/O header layout on the sheet above is actually reversed compared to the Seeedstudio layout.  Use the pin names and colour reference instead to determine which pin is which;

Color Reference – MISO is pin 10, GND is pin 1

Going from those two, it’s pretty straightforward to wire up the ATtiny85 as follows;

BusPirate Label BP Color ATtiny85 Tag AT Pin
GND Brown GND 4
+5V Orange Vcc 8
CS White RESET 1
CLK Purple SCK 7

After the BusPirate is all wired up, it’s time to set up a new version of avrdude to work with it.

Step 2 – Setting up the new avrdude


Unfortunately, the version of avrdude that comes with the Arduino 22 IDE is positively ancient and doesn’t support the Bus Pirate.  The latest 5.10 version of avrdude does, so you’ll need that.  You can pick up a pre-compiled binary from here.  Extract out the files.

Pop open a command prompt, go to the folder that you put this new version of avrdude in, and then run the following command;

avrdude -c buspirate -P COM8 -p t85 -v

You should see a whole bunch of useful info, and most importantly you should see a list of the fuse settings.  If so, fantastic, it works!

Step 2a – Building your own AVRDUDE


This is an advanced step.  You don’t need to do this if you want to use my pre-compiled AVRDUDE in Step 2.  But if you want to build your own, follow these instructions to make it easy(ish).

  • Download and install MINGW and MSYS.
  • Use TortoiseSVN to fetch the latest AVRDUDE into C:\MinGW\msys\1.0\home\\avrdude
  • Download the latest libusb-win32 from
    • From include\usb.h in that package, copy that to C:\MinGW\include and rename as usb.h
    • From lib\gcc\libusb.a, copy that to C:\MinGW\lib
    • From bin\x86\libusb0_x86.dll, copy that to C:\MinGW\bin, and rename as libusb0.dll
    • Drop a copy of libusb0.dll into your avrdude repository.
  • Update MinGW and install additional components
  • mingw-get update
          • mingw-get install autoconf
          • mingw-get install automake
          • mingw-get install msys-bison
          • mingw-get install msys-flex
          • mingw-get install msys-patch
  • Get and install the BusPirate patch for the AVRDUDE SVN
    • Download the patch file from the link above, and copy it into C:\MinGW\msys\1.0\home\
    • In mingw, do the following;
      • cd avrdude
      • patch < ../avrdude_buspirate.patch
    • You should now have a patched AVRDude, which has some optimizations to make it work a lot faster than default.
  • Configure and build
    • ./bootstrap
    • ./configure
    • make
    • strip avrdude.exe
  • Now, copy out the following files, they make your new avrdude;
    • libusb0.dll
    • avrdude.exe
    • avrdude.conf

Step 3 – Programming Fuses on the ATtiny85


Next up, we’re going to want to set the fuses on the ATtiny85 to suit what we want to do.  In my case, I want to run at 8MHz using the internal oscillator.  Using the link above, this means I want to set the lfuse to 0x62 and the hfuse to 0xDF.  In my particular case, the fuses are set correctly by default, but if they weren’t you could reconfigure them with;

avrdude -c buspirate -P COM8 -p t85 -v -U lfuse:w:0x62:m -U hfuse:w:0xDF:m

Note that the default fuses will set the ATtiny85 to use the internal RC oscillator and divide it by 8.  This means that your ATtiny will actually run at 1MHz.  If that suits your task, fantastic – it’ll draw less power that way.  I’m leaving things at default just for the sakes of making it work.  If you do turn off CKDIV8 to get an 8MHz clock, you’ll have to change below to 8000000L to suit.

And now, a warning.  It’s possible to brick your ATtiny by setting the wrong fuses.  In particular, if you set RSTDISBL=0 (ie, enable the reset pin to be used as an I/O pin), you remove the ability to be able to program the ATtiny with a normal ISP, and you’ll have to use a high voltage programmer in order to fix it.  So don’t do that unless you are really sure your code is going to work and you really need that sixth I/O.

Anyway, set the fuses as required, and then we’re going to integrate it all into the Arduino IDE.

Step 4 – Arduino IDE Integration


First off, we’ll need to copy in our compiled avrdude.  Fortunately, the cygwin1.dll is compatible between the version 22 IDE and the avrdude linked above.  Assuming you installed the IDE into c:\arduino, copy avrdude.exe, libusb0.dll, cygusb0.dll and cygwin1.dll into c:\arduino\hardware\tools\avr\bin .  Then copy your avrdude.conf into c:\arduino\hardware\tools\avr\bin .

Next up, you’ll need to reconfigure your default Arduino boards so that you can upload using the new avrdude (which requires programmer type ‘arduino’ instead of ‘stk500’).  To do this, copy c:\arduino\hardware\arduino to the hardware folder in your sketchbook, so you have a folder hardware\arduino in your sketchbook.  This causes that new copy of the Arduino platform definition to override the built-in version in your IDE.  Edit programmers.txt and comment out (put #’s at the start) of any lines for programmers you don’t have, and then edit boards.txt and comment out any boards you don’t have.  For the Arduino Uno board, edit the uno.upload.protocol line and change it to read uno.upload.protocol=arduino .  This causes the IDE to use programmer type “arduino” when calling AVRdude, which is correct.

Download from the link above.  Follow the instructions in that link in order to extract out the attiny45_85 folder into your hardware folder.  Then, edit your boards.txt file that you extracted.  What you’ll need to do here is to comment out (add #’s at the beginning of the line) any of the options you don’t care about, and add in a new one.  The new option we’re adding down the bottom is like this; (w/ BusPirate)

Next, you’ll need to create a programmers.txt in the same folder as your boards.txt, and set its content to the following;

Once that’s done, you should be set up.  Fire up the Arduino IDE, and in the Board selection, you should see your new “ATtiny85 (w/ BusPirate)” option.

Step 5 – Testing!


We’re nearly home free.  Fire up the Arduino IDE, and open the Blink sketch.  Change any references to pin 13 to 0.  Pin 0 corresponds to physical pin 5 on the ATtiny85, and is the MOSI line on the chip.  That line corresponds to BusPirate pin 8, which is what we’ll be looking at shortly.

Upload the sketch.  You should see some Cygwin warnings, and then a line about putting the BusPirate into binary mode.  You should see nothing else (the IDE is a little quiet, unfortunately).

After that’s done, hopefully everything will work.  In order to avoid having to go as far as pulling out the ATtiny85 and hooking a LED to it, we’ll utilize the BusPirate to monitor that line toggling!

Using a terminal client of some type, connect to the BusPirate.  You should be in Hi-Z mode.  Type “m9” and hit enter to go into Direct I/O mode.  Hit ‘v’ and press enter and you should see all the connected lines in state “I” (input).  That’s what we want.  Now, type “pW” and press enter.  This disables the internal pullups if they happen to be on, and then turns on the power supplies.  This will cause the ATtiny85 to power up and (hopefully!) start pulsing pin 8 on the BusPirate.

Now, type “v” and press enter a few times, and you should see pin 8’s state transition from L (low) to H (high).  If that happened, then that indicates that the ATtiny85 has been successfully programmed with your code from the Arduino IDE!

Coming up soon, some optimizations to AVRdude to make it work faster (I hope).

Bus Pirate Received!

Just got my delivery made, and now I have a Sparkfun Bus Pirate!  One thing I noticed straight away is that the cable provided has exactly the same colour scheme as the original Seeedstudio version, but the shroud on the 10-pin header is reversed, meaning that all the colours were swapped.

Since I wanted to use this chart, a little operation was in order.  Fortunately it turns out that you can wiggle the shroud off the pins and reverse it, making the colour scheme all match up the way it should, although it does mean your cable is now coming out the wrong end.  Doesn’t matter much.

My intention is to use the thing to do I2C testing, as well as use it as a standin ICSP programmer (newer versions of AVRDUDE support it) for 8-pin AVRs.  And lastly, as a cheapo JTAG debugger for when I start getting into ARM.

I’m in the midst of setting up OpenOCD to test it out for JTAG, so I’ll blog about my experiences there once that’s done.

A very cool little bit of kit.  Now I just need to find a suitable box.  The thing is tiny, about the size of a matchbox…

ArduinoISP – Burning the default fuses for an ATmega328p

When you buy a brand new, blank ATmega328p, it comes with a set of fuses (basically hardware settings) which give it maximum reliability, but they aren’t the default that is required for the chip to work with the Arduino IDE and libraries.  In order to burn the correct fuses onto it, run the following command (this assumes that you’re using Arduino-as-ISP on COM4);

avrdude -pm328p -cstk500v1 -b19200 -PCOM4 -v -C ..\etc\avrdude.conf -U lfuse:w:0xFF:m -U hfuse:w:0xD6:m -U efuse:w:0x05:m
Run the command from the hardware\tools\avr\bin directory inside your Arduino IDE install.
Short post, I know.  This info’s mostly for my reference, but should be handy for others too.