USBasp programmer - the build

I finally built myself a programmer!!!

Loading drivers on a 64-bit system

Unfortunately my Windows 7 64-bit insists that drivers be signed, and these are not. I read up on it and found that to sign the drivers myself I would first need a VeriSign certificate at $399 a year :D so I gave that up.

2009-12-16: I have just learned that the certificate can be had for $99 a year (that is 284.65 PLN - still too much for a small non-commercial project), by following the link on the Winqual Help page.

There are plenty of recipes on the internet for getting unsigned drivers to load, but almost none of them worked here, and some even did the system a bit of damage (to the point where practically no driver other than Microsoft's own would load at all). The only thing that did work was Driver Signature Enforcement Overrider 1.3b.

To make the system load the libusb drivers, after installing them you have to sign every sys and dll file (the Sign a System File option in DSEO):

c:\windows\system32\drivers\libusb0.sys
c:\windows\system32\libusb0.dll
c:\windows\syswow64\libusb0.dll

Installing further devices can, however, overwrite those signed drivers with unsigned versions, so I did it slightly differently. I signed the files before I installed the device:

bin\win-driver\libusb_0.1.12.1\libusb0.dll
bin\win-driver\libusb_0.1.12.1\libusb0.sys
bin\win-driver\libusb_0.1.12.1\libusb0_x64.dll
bin\win-driver\libusb_0.1.12.1\libusb0_x64.sys

That way the drivers do load :D (p.s. people write that you have to turn UAC off; I turned it off before doing all this and switched it back on once everything worked - and it still works)

A USB PID of my own

One more thing. I found out that FTDI hands out unique PIDs within its own VID to its customers. I thought I would be clever and build my own programmer with my own drivers. I wrote them an email. All I had to give was

• my surname
• a company name
• a country
• an email address

and I was given eight PIDs of my own, free of charge. :D I wanted to use one of them for the programmer, but the driver signing question stopped me (and while I was at it I noticed that avrdude would not see my programmer anyway)

USBasp

There will be no photographs of the programmer for now because I have no camera, but it looks roughly like the one modelled in the previous post.

I used the software in version usbasp.2009-02-28 from the USBasp author's site. For programming I use avrdude. I write the programs in Code::Blocks (in the post-build steps I added

avrdude -q -p m8 -c usbasp -e -U flash:w:$(TARGET_OUTPUT_FILE).hex

so that the moment it compiles, the software lands in the microcontroller) together with WinAVR-20090313.

I am not going to repeat the assembly instructions, because everything is on the author's site and, in Polish, on Mirley's site

If anyone has questions, do get in touch :)

Debugging over RXD/TXD

The author of the programmer allowed for sending data using the UART in the programmer's microcontroller, but so far that feature is not supported. I am in the middle of modifying the firmware and writing an application to make use of it.

At the moment I can already switch LEDs on and off from an application on the PC :D Now I have to learn to drive the UART.

AVRUSBBoot vs BootloadHID

To make it easy to modify the software in the programmer, I decided to put a bootloader into it.

The trouble with AVRUSBBoot is that it needs drivers (libusb - the signing problem) and that it uses the same VID and PID as USBasp, so Windows installs the USBasp drivers straight away and the loader cannot see the device (because it checks not only the VID and PID but also the device name and vendor)

BootloadHID does a far better job. It needs no drivers at all - it uses the ones built into Windows.

In both cases the principle is the same. The bootloader is placed at the end of the flash memory and the fuse bits are set so that execution starts there after the microcontroller is reset. If the right pins are in the right state after a reset (the so-called bootLoaderCondition), the bootloader code runs and the computer sees the device as AVRUSBBoot or as a USB input device, as the case may be. The loader then writes the real firmware into the microcontroller.

Do remember that when you change bootLoaderCondition you also have to fix the pull-up settings for those pins (if the condition is a pin shorted to ground). I used the Slow SCK jumper from USBasp as the condition for entering the bootloader.

static inline void  bootLoaderInit(void)
{
    PORTC = (1 << PC2); /* activate pull-up for key */
    _delay_us(10);  /* wait for levels to stabilize */
}

#define bootLoaderCondition()   ((PINC & (1 << PC2)) == 0)

2009-11-22:

Unfortunately, using a bootloader in the programmer did not work out. The programmer itself refuses to work properly.