USB AVR Programmer Not Compatible With Mac OS Workaround

I took advantage of the recent sale on and picked up a Baby-O m328P combo with the USB AVR Programmer as well as a 3pi. I was quite excited. However, I failed to notice that the USB AVR Programmer is not compatible with any Mac OS. I found that out yesterday when I was trying to get everything working.

Eventually, I discovered that the core of the issue is that Mac OS X will no longer recognize a USB-to-serial device. I believe this feature was taken away around update 10.4.8. Of course, that’s pure speculation derived from many posts I’ve read around the internet. I tried all sorts of things to get it to work, to no avail.

So, here’s my workaround. Hopefully this will work for others.

Hold on a moment, before I begin, I have to confess something. There is a bit of a mystery that should be mentioned. When I use System Profiler on my Mac, I notice under the USB section the Pololu USB AVR Programmer is listed. Why? I have no idea, but I have some theories. Here is what I suspect. I installed the CP2102 drivers for Mac Os X located here:

That might have created it. I may uninstall it later today to see if it disappears. Also, I followed the steps here for fixing the Pololu.kext:

I’ll continue. This workaround involves using Sun’s VirtualBox to run an instance of Ubuntu 10.10. Ubuntu 10.10 recognizes the USB AVR Programmer and assigns it a ttyACM0 and ttyACM1 just as Mac OS X should do if it wasn’t so busy trying to look cool.

So, I headed over to and downloaded the 32-bit version of 10.10. (iso)

Next stop … I downloaded VirtualBox 3.2.10 for OS X hosts here: … 23-OSX.dmg *

I installed VirtualBox then told it to build a new Linux virtual box using the Ubuntu 10.10 iso. I gave the virtual box 8 GB of hard drive space and let it use 768MB of RAM. I installed Ubuntu in lieu of ‘Trying Ubuntu’. Installation takes a bit, but remember, you only have to do it once.

Once Ubuntu is up and running, use Synaptic Package manager to install gcc-avr, avr-libc, binutils-avr, and avrdude, as directed by the m328P user guide.

Now comes the tricky part. I plugged in the USB AVR Programmer. I opened a Terminal window and did a ‘ls /dev/tty*’ and looked for /dev/ttyACM0 and /dev/ttyACM1. They weren’t there. Then I noticed a tiny little USB-looking icon in the border of the Virtual Box window. Clicking on that, I was able to select the ‘Pololu USB AVR Programmer’. Once I did that, I reissued a ‘ls /dev/tty*’ and what do you know, ttyACM0 and 1 were there!

I did a quick test by following the user guide for BlinkLED project and it worked. The only issue I’ve found is that there appears to be an problem issuing consecutive commands through avrdude to the programmer. The programmer will timeout over and over again and the red LED will be lit indicating an error. Unplugging the device and plugging it back in (and selecting it in the Virtual Box USB menu) gets it working again. I’ll have to keep troubleshooting this.

So, there you have it. Not the cleanest solution, but it works. Not to mention, now you have a good Linux build to play with!

Here’s a summary:

  • Get your Mac to recognize Pololu USB AVR Programmer in System Profiler by installing CP2102 driver for MAC (theory!!)
  • Download and install VirutalBox
  • Download Ubuntu 10.10
  • Create new VirtualBox running Ubuntu 10.10
  • Download avr tools
  • Plug in and program

Good luck!


  • NOTE: VirtualBox is only for Intel Macs. I haven’t tried this solution on my PowerPC Mac yet using Q. But, I’ll probably do that later. I’ll report back on the success or failure of that.

Hello. I’m glad you got your programmer working on your machine!

We’ve experienced problems similar to yours–where we have to disconnect and reconnect the programmer after each programming when we’re trying to use it from a VirtualBox virtual machine–and unfortunately we don’t know a workaround.

It’s unlikely that the CP2102 drivers had an effect. Those drivers were for our older AVR programmer, not the new one which you have. USB has a standard mechanism (string descriptors) that lets the PC get the name of any device attached to it even if no drivers are available, so it’s no surprise to me that an entry for “Pololu USB AVR Programmer” showed up in your System Profiler.


Thanks for the note David. That makes sense.

I’ve been troubleshooting the disconnect problem with the Virtual machine. Haven’t got anywhere with it yet. I’ll keep plugging away. Do you know of a way to find out what the errored state of the programmer is (red LED indication)? Or is it simply a non-zero event?

If the red LED is on, you should be able to run PgmCmd to figure out what the error is (on a Windows machine you could just run the configuration utility that comes with the programmer, but that program isn’t available on Linux). PgmCmd is a command-line utility that you can compile. It’s part of the Pololu USB SDK:


Mac OS X currently does not support serial devices contained in IAD composites. Everybody else does. It’s claimed that they will be supported soon. … 00040.html

It’s still possible to communicate with the device from userspace using libusb. I hacked a quick proof of concept out of ekeyd; all it does is talk to a hardwired bulk endpoint, which is good enough for some ACM devices, apparently. Passes a loopback test, but I have no idea what baud rate it’s running at. Note that this is source code, with a libusb dependency, not useful in its present form, and I don’t know if I care enough to try to make it usable (especially if Apple fixes the CDC ACM driver “soon” and in 10.6.) Feel free to make it more useful.

Source code:

Note that replacement firmware could present a single pure ACM device, which probably would be supported by OS X (the Arduino Uno seems to have no problem.) If had the firmware source I’d probably have done that first.

Hello, nop.

Welcome to the forum and thank you for the good news about Mac OS X. If Apple makes their driver support CDC-ACM in a composite device with IADs it could allow many of our products to work on a Mac.

Using libusb is a decent idea. But there is lots of existing software out there (such as avrdude and kermit) that is designed to talk to a serial port. Is there anyway to have your libusb program create a special type of file that behaves like a serial port? (e.g. behaves like /dev/ttyACM0)

That is correct! In fact, last week, we quietly released a firmware modification that does just that. You can download it from here: This will let you program AVRs from your Mac, but won’t let you use the TTL serial port or the SLO-scope.


Well, well, well. This is good news.

nop, thanks for the code. I’ll check that out too!

Pseudoterminals mostly behave like serial ports, although I’m not familiar with mechanisms for control data like baud rate or stop bits to pass through. As an experiment (and in the interest of not adding yet another programmer module to avrdude) I changed the endpoint bridge to allocate and talk to a pty.

New version:

The bridge now runs like “./tusb-pty -l /tmp/prog” where /tmp/prog is a symlink created to point to whichever /dev/ttys008 etc slave pty is allocated. This is good enough to run avrdude and dump memory:

avrdude -n -v -v -p m328p -c avrisp2 -P /tmp/prog -U flash:r:/tmp/mem:i

although you’ll note I’m not brave enough to turn off the “-n” read-only flag, at least without a socketed device and HV programmer in reach. Running in “-t” terminal mode results in communication timeouts (but that mode’s not critical.)

The “-s” option to tusb-pty talks to the TTL serial port instead of the AVRISP emulator, but this has only been lightly tested with kermit and a loopback.

Cool–that should help a bunch of people while waiting for Apple to release better drivers. To be honest, I’m not super-committed to OS X as a dev platform; it’s mostly chance the closest machine to my targets wasn’t a Linux box. It’s kinda fun to try something different–or maybe I’m just procrastinating on writing that interrupt-driven multichannel tachometer :slight_smile:

That’s great that you were able to get avrdude talk to the programmer using a pseudo terminal and libusb!

I downloaded your package and skimmed through the README and source files. I noticed this:

I suspect that the “weird state” is that the programmer has not received a USB Set Configuration request. Complying with the USB 2.0 specification, the programmer does not respond on any non-zero endpoints until it receives a Set Configuration request. Before it gets the Set Configuration request, you should see the programmer’s green LED slowly blinking. What is the green LED doing during the weird state? Maybe you could get rid of reset-ef-02 if you just have tusb-pty.c send a Set Configuration request.

AVRDUDE’s terminal mode (-t option) never works with our programmer because our programmer has a timeout that brings the device out of programming mode if no commands have been received for some time (350ms if I recall correctly). This is a safety measure to prevent unintended operations on the target AVR.

I’m curious why you chose to use libusb 0.1 instead of libusb 1.0, which is better in all ways as far as I can tell (unless you want to run your code on Windows, which you don’t).


I can believe that, but I can’t reproduce the problem (am I happy or sad about this?) after rebooting my Mac. So I guess the OS is doing this.

Anyway, avrdude works (at least enough to program BlinkLED and serial1.c) and if I run one “tusb-pty -l /tmp/prog” and one “tusb-pty -s -l /tmp/ser” I can get to both the programmer and the serial port at the same time. kermit seems happy; I changed the libpolulu serial1.c example from 9600 to 19200bps which appears to be the (reasonable) default for the USB AVR device’s serial port. I faked a Big O middle button and that worked with the example too. (Had to check device-initiated transmission, since everything else had been in a host request/device response pattern.) I haven’t tested overrun behavior.

Ah, fail-safe makes sense; telling me that’s known gave me enough confidence to start programming a Baby O. (OK, and also I had to put headers on it first; the last time I soldered anything more serious than perfboard or stuff inline in a cable was like twenty years ago, so I needed to practice a bit too. “Was that a cold solder joint or just not perfectly shiny?”)

ubuntu@ubuntu$ apt-cache depends ekeyd-uds | grep usb
  Depends: libusb-0.1-4

So it wasn’t so much choice as “that’s what the code I hacked up–er, my fine example of software reuse declared as a dependency.” Also I might have been thinking I could use the libusb library shipping with the OS X crosspack, but it wasn’t compatible when I checked. It’s possible libusb 1.0 would be a minor change but I haven’t gotten around to looking.

The current state is good enough for my purposes for now. A general version would do something about baud choice and control signals on the serial port (by watching the pty for termios changes?) and there’s still the matter of an end-user software distribution. I imagine this could be hooked into a wrapper GUI app (launch at login?), or installed systemwide with launchd or something. Eliminating the macports requirement is important even for people comfortable with gcc.

I’ll probably do some minimal cleanup and get this written up on a web page that search engines index (other hobby embedded people could use this too) but if I build an end-user installer soon it’s probably a sign I’m blocked on some other project. And Apple could eliminate the need for all this in the next patch release for all I know.

So, I’ve updated the firmware on the programmer and my iMac (10.6.x) recognized it just as described in the user guide. Many thanks to whoever developed the firmware.

I’ve tried to use the programmer on my iBook running 10.4.11, but the OS doesn’t recognize the device like my iMac does. Does anyone know if the new firmware only works with OS X 10.5 and above?

Again, thanks for the updated firmware.

Hi. Glad it worked for you with Snow Leopard (10.6.x), which is the platform we used for our own testing.

Regarding the iBook, after digging a little deeper, we made another tweak to the firmware modification that we think will improve its compatibility with older versions of OS X. It is posted as firmware version 1.02nc for download from section 5.a of the Pololu USB AVR Programmer User’s Guide.

We retested this new version (1.02nc) using an up to date Mac (10.6.5), and it still works fine. We don’t have an iBook conveniently at hand for testing, so we can’t 100% promise that it will be compatible with the older system. But if you want to try it out, you can let us know how it goes. Good luck!

- Jan H.

Hmm … I’ll have to give this a try.

I do note that when I used a Windows PC to update the firmware the last time, the Windows PC would no longer recognize the USB Programmer after the firmware update was successful. I suspect that when I go to try this again, I will be unable to update the firmware because of this situation. Is there a way to update the firmware using Mac and avrdude?

*** Update:
My suspicions proved true. The Windows PC will no longer load the drivers for the programmer. I tried to uninstall and reinstall the driver, but that did not work. I looked a little deeper and found that the device is reporting the Manufacturer ID as 90 instead of 81 (I’m going by memory so I might be a little inaccurate). I tried changing the inf file to reflect what the OS is seeing but that still failed to install the drivers. Ah well.

*** Update #2:
Success. I followed the directions for forcing the programmer into bootloader mode by shorting the small pads while plugging the programmer in. I was then able to update the firmware. At first, I tried version 1.03, but that didn’t work. However, 1.02nc worked like a charm with Mac OS X 10.4.11!!!


I use it on windows and worked fine. But I want that my mac works too then I updated my firmware to 1.02nc but my windows does not recognize my programmer anymore and avrdude is not working on macosx.

I’m using atmega328p with arduino bootloader and using this line:

avrdude -p m328p -c arduino -P /dev/cu.usbmodem00010691 -U flash:w:TrunetClock.hex

Also, I tried to downgrade my firmware but after trying short bootloader pins a lot I’m not able to put programmer in bootloader mode to upgrade to 1.03 and use it on windows again.

Do you have any idea:

  1. Making my avrdude working on macosx
  2. Upgrade/Downgrade firmware to use it again on windows.


Wagner Sartori Junior

Where did you get avrdude from, how did you install it, and what exact error message or unexpected behavior is happening? Without knowing that, all I can suggest is that you download the CrossPack for AVR Development.

Please follow the instructions on this page:

The important thing is that the bootloader pads must be shorted when the programmer powers on. The programmer can be inadvertently powered through its programming cable, so that needs to be disconnected before trying to get it in to bootloader mode.