Patch to Lcsoft USBasp V2.0

(tópico que postei no AVRfreaks)
I present a firmware patch for the Lcsoft USBASP V2.0, a cheap and very common AVR programmer from ebay:
When using the slow SCK option (jumper J3), the connection from AVRdude to the target AVR may be unstable:
- sometimes the signature is not recognized...
- sometimes the program verification fails somewhere...
- etc.
With a logic analyzer, I discovered the MOSI and SCK pins are NOT following the serial programming datasheet specification, which uses CPOL=0 and CPHA=0. The USBasp is actually clocking the MOSI line at the SCK rising-edge.
I reverse engineered the chinese programmer and found the bug. The poor code does SPI emulation with the following pseudo-code:
This patch reorder things, resulting in the pseudo-code:
The digital waveforms below shows the effect of the patch on the MOSI line:

The 0xAC and 0x53 bytes is the beginning of the Programming Enable command.
The patched firmware is available from here: (11KB)
https://docs.google.com/file/d/0By5yf3g1ZJa9UnNLWWcwUXNWaWM/edit?usp=sharing
You need another AVR programmer to update your Lcsoft USBASP. This can easily be done with another USBASP with the following command-line:
Hope this patch helps to solve some of the painful instability issues with this programmer.
Note 1: I've tried to reflash using the 2009 and 2011 firmwares from www.fischl.de/usbasp, and I got the usbasp not recognized as an USB device.
Note 2: Tested with atmega88 devices. Use it at your own risk.
I present a firmware patch for the Lcsoft USBASP V2.0, a cheap and very common AVR programmer from ebay:

When using the slow SCK option (jumper J3), the connection from AVRdude to the target AVR may be unstable:
- sometimes the signature is not recognized...
- sometimes the program verification fails somewhere...
- etc.
With a logic analyzer, I discovered the MOSI and SCK pins are NOT following the serial programming datasheet specification, which uses CPOL=0 and CPHA=0. The USBasp is actually clocking the MOSI line at the SCK rising-edge.
I reverse engineered the chinese programmer and found the bug. The poor code does SPI emulation with the following pseudo-code:
- Código: Selecionar todos
spi_byte_exchange(byte c)
{
i = x = 0;
repeat
{
MOSI = c.bit7; // output
x = (x << 1) | MISO; // sampling
SCK=1; // rising-edge
wait();
SCK=0; // falling-edge
wait();
c <<= 1;
if ( ++i == 8 )
return x;
}
}
This patch reorder things, resulting in the pseudo-code:
- Código: Selecionar todos
spi_byte_exchange(byte c)
{
i = x = 0;
repeat
{
MOSI = c.bit7; // output
wait();
SCK=1; // rising-edge
x = (x << 1) | MISO; // sampling
wait();
SCK=0; // falling-edge
c <<= 1;
if ( ++i == 8 )
return x;
}
}
The digital waveforms below shows the effect of the patch on the MOSI line:

The 0xAC and 0x53 bytes is the beginning of the Programming Enable command.
The patched firmware is available from here: (11KB)
https://docs.google.com/file/d/0By5yf3g1ZJa9UnNLWWcwUXNWaWM/edit?usp=sharing
You need another AVR programmer to update your Lcsoft USBASP. This can easily be done with another USBASP with the following command-line:
- Código: Selecionar todos
avrdude -p m88p -P usb -c usbasp -U flash:w:USBasp_lcsoft_patched.hex
Hope this patch helps to solve some of the painful instability issues with this programmer.
Note 1: I've tried to reflash using the 2009 and 2011 firmwares from www.fischl.de/usbasp, and I got the usbasp not recognized as an USB device.
Note 2: Tested with atmega88 devices. Use it at your own risk.