USBASP teething woes

For an AVR newbie, there can be nothing more frustrating than the feeling of being ditched by the usbasp programmer the moment he ventures out on his own.

A newbie usually starts with an usbasp programmer and a development board. After the initial struggle of setting up the drivers for the programmer and configuring Atmel Studio with avrdude, life seems joyful when the first blinking LED program work seamlessly.

In my case, I use the following devices. The red one is the usbasb programmer from USBProg and the other one is the development board (with an onboard ATMEGA 16A PU chip) from provotech.in.

Once the initial familiarization is over, the next logical step is to move to a breadboard and be freed from the constrains of the development board. In doing so, we pick up the standard usbasp 10 pin FRC pinout and map it to the programming pins of ATMEGA 16 - simple, right? BTW - one of the reasons I love 16A to start with is because the pins are wonderfully grouped and are not scattered around. Anyway, this is how the ideal in system programming connections look like.

So, where is the problem? The problem is that the above does not work and avrdude keeps saying that it is not able to communicate with the device.

• First doubt - maybe the connections are goofed up... check.. no they look ok...
• Second hunch - maybe the chip is fried .. check with another chip... oops the second chip doesn't work too....
• Third attempt - let's try with the 16A from the board ... lift the chip, place it on the breadboard... try to flash.. nope.. not working.. 
• Fourth attempt - place the 16A back on the development board.. try with the programmer .. it works.... wow.. 
• Fifth attempt - Search google desperately... read through the longish message board trails.. you see recommendations of upgrading firmware... but you are already on the latest... 

At this point, nothing really makes sense anymore. Desperation, amalgamated with frustration sets in and you make up your mind to close shop. 

The root cause and solution

After tracing the male FRC pins on the usbasp PCB back to the Atmega8 (in accordance with the official usbasp schematics), I found that - the ISP pinout from the usbasp board was non standard and did not match with the standard 10 pin configuration!

In fact, mine looked like the following.. 

Great revelation, now the connections can be rewired and ..... NOOOO.. it still doesn't work. The usbasp programmer is still not able to communicate with the MCU. Darn!! double darn, it was such a good lead!

Upon further sleuthing it comes to notice that the the programmer is operating at 8 MHz oscillator while our virgin chip is operating at a 1Mz factory default. Ergo, we need to slow down the SCK sync by using the Slow SCK jumper (JP3 in the original schematic).. we do that and voila, the virgin chips start working...

Wonderful!

Now, just for the sake of completeness, we try to see if our solution is able to handle the ATMEGA 16A chip on the development board. So we pry it open, put it on the breadboard, connect the jumpers and poof!.. it doesn't work. Some more head scratching and the realization dawns that the chip on the development board is not a virgin! It has been fused to work with an external oscillator - which makes sense since the the Slow SCK jumper is not required when working with the development board and there is a 8 MHz onboard oscillator connected to the XTAL pins on the board). So, we slap in an external 8 MHz oscillator on the bread board, remove the JP3 and wow, it works now!

Hope this helps someone who is running down the rabbit hole, like me and my son did.

Oh, btw - a nifty tip, if you end up getting yourself a usbasp programmer with a non standard pinout, you are better off desoldering the 10 pin make FRC connector and soldering a 6 strand FRC directly. Furthermore, it is a good idea to make yourself a tiny flash fang at the other end with a 6 pin male berg strip and a tiny strip board cutout. It digs its fangs perfectly onto the breadboard when you want to flash something on the chip.