Month: June 2015

The V2 toybrain boards have the diagnostic LED on analog input 6, which isn’t able to also act as an IO pin. Other than that, though, they work. This entry is mostly a note to me to fix that if I make another rev of the board.

The V2 Toybrain boards are getting pressed into service for an art project that I’m working on, so I’m trying to get a set of them up and running. I use Linux, so the tools for talking to AVR microcontrollers are the Arduino IDE, and avrdude, which the Arduino IDE uses.

I started today by telling the Arduino IDE that my boards are a Lilypad Arduino with an ATMega328 on them. This isn’t true, but the electrical design of the board is such that this is close enough. I also informed the IDE that I had a USBTiny ICSP programmer. That bit is true. I had high hopes (because I’m lazy, and configuring the IDE is not the problem I’m trying to solve) that this would let me just hit the “burn bootloader” option in the IDE. Such is not the case. I got the error message:

I’m a normal user, and the permissions on the USB device are not such that mere users can talk to it. I figured I’d double-check by using avrdude as root (so the permissions would be ok). Then I ran into my next problem:

The version of avrdude I have is 5.11.1, and doesn’t ship with a hardware definition for the ATMega328, just the ATMega328P. The P is for Picopower, and isn’t related to anything I’m doing (it mostly relates to the technology used to make the chip, and some power handling options like brownout detection). To get around this, I opened /etc/avrdude.conf and copied the ATMega328P hardware definition. Then I changed the descriptions and a few of the fuse bytes to match the parts I do have, and saved the file. Now avrdude doesn’t flip out about my chips.

Unfortunately, programming them through the Arduino IDE is still a bad plan, as the configuration for the LilyPad Arduino isn’t close enough to the hardware I’m using. Specifically, the Lilypad/328 configuration sets the lfuse bits to use an external oscillator, and I’m using the internal oscillator. Once the bad fuse settings are burned in, the chip doesn’t communicate unless it has a 8Mhz crystal attached to it. The error message from avrdude is:

I added a crystal (temporarily) to the bricked boards so I could reset the fuses, and they worked fine after that. One of them had the chip on 90 degrees from the proper orientation too, and gave the same error as the chips with the bad fuses, so that error can be anything from the wiring being bad to the chip being configured wrong.