Firmware does not work on some USBISP clone with ATmega88 about usbasp HOT 31 CLOSED

Maybe it's related with this aleh/usbisp#6 (comment)

I'll try it tonight

from usbasp.

Unfortunately I don't have a similar device to test .

Just ordered some from here but they'll take some time to arrive .

from usbasp.

I'm thinking that the MS OS 2.0 Descriptors combined with enabling long transfers may cause problems .

BTW, all my tests were done using a atmega88pa . I tried to find / source atmega88 ICs ( DIP, TQFP ) but except ebay and aliexpress, all the known ( to me ) distributor's stock are zero ....

from usbasp.

@dioannidis

FYI one of the two m88 USBISP clone devices now work under Linux and Windows. It is quite strange. This is a dual boot laptop with Windows 11 and Ubuntu 20.04. It did not seem to work under Windows initially. I reboot the machine and tried it under Linux and it worked there. Rebooting again to Windows and it now works under Windows.

BTW, I have problem flashing the latets firmware on 16-July-2022 (verification failed, but could be due to shaky hands to use a wire to short the two pads). Then I use the older version on 28-Feb-2022 and it seems to work fine.

The quality of the two solder pads for the FW upgrading are pretty bad. So I would not touch the two good boards now.

As for the 3rd board, it has some HW problems now: the two solder pads used for FW upgrade seem to be bad now and I can not connect to the ATmega88 CPU. I need to see if I can fix the solder pads or not.

In summary, I am no longer sure if this is a bug or not. It could be a false alarm for the ATmega88 USBISP v5.0 clones.

As for the minimum ATmega8A USBASP clone, I will test it again. It came with very old usbasp FW and that is why I tried to upgrade.

from usbasp.

In summary, I am no longer sure if this is a bug or not. It could be a false alarm for the ATmega88 USBISP v5.0 clones.

As for the minimum ATmega8A USBASP clone, I will test it again. It came with very old usbasp FW and that is why I tried to upgrade.

All the atmega8a usbasp clones ( I have five, two of them doesn't have the rxd/txd pins exposed) work without a problem . Bad flashing maybe ?

from usbasp.

Rebooting again to Windows and it now works under Windows.

Could you please "clean" the windows registry reg USBasp VID/PID keys ?

I use usbdview in administrator mode to delete the usbasp's usb registry keys during development ....

from usbasp.

BTW, for the two usbasp clones with ATmega8A and UART lines extended to the 10pin ISP connectors, the HID UART function seems to work fine (just a simple loop-back test).

C:\work\avr\usbasp\bin\hiduart test\windows-x86_64 [master ≡ +10 ~0 -0 !]> .\USBaspHIDUART.exe -i 0 -w

Enumerating USBasp HIDUART (Hid Api Library Version : 0.12.0 )

USBasp device configuration
---------------------------
Crystal : 12000000
Baud    : 9600

1
2
3
4
a
b
c
d

C:\work\avr\usbasp\bin\hiduart test\windows-x86_64 [master ≡ +10 ~0 -0 !]> .\USBaspHIDUART.exe -i 1 -r

Enumerating USBasp HIDUART (Hid Api Library Version : 0.12.0 )

USBasp device configuration
---------------------------
Crystal : 12000000
Baud    : 9600

1234abcd

from usbasp.

@dioannidis
Sorry for the false alarm on both accounts (ATmega88 USBISP v5.0 clone and ATmega8A USPASP minimum version).

Updates:
Now all my 7 usbasp/usbisp clones are runing your latest firmware and work fine. Three of the 4 ATmega8A based usbasp clones are able to run the HID UART tool as they have the two UART pins on the 10-pin ISP connectors.

from usbasp.

If I don't ask too much, is it possible to test the libUSBUARTTerminal ( which is a GUI HID UART Terminal ) when you have some spare time ?

I'll appreciate the feedback .

No problem. It seems to work rather well. I am again using two usbasp loop-back for the testing.

A few potential improvement ideas.

1. Other than serial number, maybe also provide the index number (0,1,etc) in the status bar. This makes it a bit easier to differentiate the two units. Take note the following two reasons.

• This is because that the default serial number is the same if the user just get the binary or build from unmodified source codes. This is actually not good as the USB standard requires unique serial number if the device has serial number (older Windows version may crash). So I just changed the serial number to 12345 and then it is easier. Maybe it is also good to have this item listed in the usbasp firmware readme as well.
• The Firmware also allows to build without serial number.

2. The label lblMonitor should be removed.

3. The About menu item now shows nothing. Probably a simple program verson and copyright notice should be there.

from usbasp.

If I don't ask too much, is it possible to test the libUSBUARTTerminal ( which is a GUI HID UART Terminal ) when you have some spare time ?
I'll appreciate the feedback .

No problem. It seems to work rather well. I am again using two usbasp loop-back for the testing.

I'm happy to hear that .

3. The `About` menu item now shows nothing. Probably a simple program verson and copyright notice should be there.

Yeap this already fixed .

from usbasp.

A few potential improvement ideas.

1. Other than serial number, maybe also provide the index number (0,1,etc) in the status bar. This makes it a bit easier to differentiate the two units. Take note the following two reasons.


* This is because that the default serial number is the same if the user just get the binary or build from unmodified source codes. This is actually not good as the USB standard requires unique serial number if the device has serial number (older Windows version may crash). So I just changed the serial number to 12345 and then it is easier. Maybe it is also good to have this item listed in the usbasp firmware readme as well.

* The Firmware also allows to build without serial number.

AFAIU, the issue is with the container id . The parent device, in composite devices, needs a container id on device level to "bind" all the functions together . I'm thinking to make a utility for patching serial AND container id ( which is a guid / uuid in fact ) of the hex file, before flashing it, for those who can't build the firmware from source .

2. The label `lblMonitor` should be removed.

Currently, if, during uart is opened, a ISP read / write command issued, then the uart closes as to not interfere with ISP.

I wanted the uart to return to open state its previous state ( to closed if it was closed or to open if it was opened ), after the ISP commands finished. So, I've implemented ( not uploaded yet ) one more hid interface for monitoring, which report the device state . With this information I can reopen the uart if it was opened before the ISP commands started.

The label lblMonitor is the current USBasp state, the extra hid interface reports.

from usbasp.

AFAIU, the issue is with the container id . The parent device, in composite devices, needs a container id on device level to "bind" all the functions together . I'm thinking to make a utility for patching serial AND container id ( which is a guid / uuid in fact ) of the hex file, before flashing it, for those who can't build the firmware from source .

This will be a good improvement.

Not so sure if you can add a feature report to update this in run-time (I have PICKit 2 which does that with a -n command).

from usbasp.

Currently, if, during uart is opened, a ISP read / write command issued, then the uart closes as to not interfere with ISP.

I wanted the uart to return to open state its previous state ( to closed if it was closed or to open if it was opened ), after the ISP commands finished. So, I've implemented ( not uploaded yet ) one more hid interface for monitoring, which report the device state . With this information I can reopen the uart if it was opened before the ISP commands started.

The label lblMonitor is the current USBasp state, the extra hid interface reports.

This is a nice improvement as well. Thanks.

from usbasp.

All three devices have the same fuses ?
If not, is it possible to take a hi res picture of the one who works and one that don't work ? Maybe different PCB ?

from usbasp.

I do not think it is the same as aleh/usbisp#6 (comment) because your code has already leave Port D as input.

from usbasp.

All three devices have the same fuses ? If not, is it possible to take a hi res picture of the one who works and one that don't work ? Maybe different PCB ?

All three clones have the same PCB and visually all have the same components. But I can not be sure about the component values.

Same fuse value as well.
lfuse: 0x55
hfuse: 0xdd
efuse: 0xf9

from usbasp.

@dioannidis
FYI, the following firmware also works. And supposedly your FW is based on his Firmware. Strange.
https://github.com/nerdralph/usbasp

Another thing, I have about 3 ATmega8A based usbasp (two different PCB design) and they all work with your USB Composite FW.

from usbasp.

@mcuee

The usbisp devices that don't work, what are their behavior ?

Do they enumerate or the ISP programming doesn't work ? If it's the latter could you please try the UART feature if they are enumerate ?

from usbasp.

The failed device does not enumerate.

from usbasp.

Thanks. Take your time. Anyway, I have alternative working FW for those two units.

from usbasp.

BTW, there is a version 6 PCB using ATmega88p. You may want to add support for that one as well.

• aleh/usbisp#8

Edit: most likely this already works.

from usbasp.

BTW, you can build the FW using MSYS2 mingw32/64 avr-gcc 8.4.0 as well.

$ make main.hex
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c isp.c -o isp.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c clock.c -o clock.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -x assembler-with-cpp -c tpi.S -o tpi.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c main.c -o main.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -c uart.c -o uart.o
avr-gcc -Wall -Wextra -Os -Iusbdrv -I. -mmcu=atmega8 -DF_CPU=12000000  -o main.bin usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o isp.o clock.o tpi.o main.o uart.o -Wl,-Map,main.map
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.bin main.hex

$ avr-gcc -v
Using built-in specs.
Reading specs from c:/msys64/mingw64/bin/../lib/gcc/avr/8.4.0/device-specs/specs-avr2
COLLECT_GCC=C:\msys64\mingw64\bin\avr-gcc.exe
COLLECT_LTO_WRAPPER=c:/msys64/mingw64/bin/../libexec/gcc/avr/8.4.0/lto-wrapper.exe
Target: avr
Configured with: ../configure --build=x86_64-w64-mingw32 --prefix=/mingw64 --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --disable-shared --disable-threads --disable-libgomp --disable-libada --with-dwarf2 --enable-mingw-wildcard
Thread model: single
gcc version 8.4.0 (GCC)

from usbasp.

Today I found another bare minimum ATmega8A based clone (no 3.3V/5V selection, less resistors, no jumper for FW upgrade -- I have to use tweezer to manually short the chip reset pin to the ISP connector RESET pin) which does not work with the FW here, but again, the firmware from https://github.com/nerdralph/usbasp works.

from usbasp.

@mcuee
Is it possible to use wireshark ( or something similar ) to log the enumeration process ?

from usbasp.

@mcuee Is it possible to use wireshark ( or something similar ) to log the enumeration process ?

This is more difficult. Let me see what I can do (under Windows 11 or Ubuntu 20.04).

from usbasp.

Could you please "clean" the windows registry reg USBasp VID/PID keys ?

I use usbdview in administrator mode to delete the usbasp's usb registry keys during development ....

Thanks. I do that as well, with various utilities. I clean up USB devices and COM ports periodically.

from usbasp.

In summary, I am no longer sure if this is a bug or not. It could be a false alarm for the ATmega88 USBISP v5.0 clones.

@dioannidis
I use a tweezer to short the two pads and it works fine to flash the latest m88.hex file (from 16-July-2022) and now the enumeration issue is gone. Looks like previously I have two issues.

1. I may have used the old firmware: https://github.com/dioannidis/usbasp/blob/master/bin/firmware/usbasp.atmega88.2011-05-28.hex
2. using cables to short the two pads are not stable. It is much better to use tweezer or things like that.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git.exe -c usbasp -p m88 -U .\hex\usbasp_m88_16Jul2022.hex

avrdude_git.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude_git.exe: Device signature = 0x1e930a (probably m88)
avrdude_git.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
                 To disable this feature, specify the -D option.
avrdude_git.exe: erasing chip
avrdude_git.exe: reading input file ".\hex\usbasp_m88_16Jul2022.hex"
avrdude_git.exe: input file .\hex\usbasp_m88_16Jul2022.hex auto detected as Intel Hex
avrdude_git.exe: writing flash (5736 bytes):

Writing | ################################################## | 100% 2.19s

avrdude_git.exe: 5736 bytes of flash written
avrdude_git.exe: verifying flash memory against .\hex\usbasp_m88_16Jul2022.hex:
avrdude_git.exe: input file .\hex\usbasp_m88_16Jul2022.hex auto detected as Intel Hex

Reading | ################################################## | 100% 1.26s

avrdude_git.exe: 5736 bytes of flash verified

avrdude_git.exe done.  Thank you.

But the programmer does not work. It think it is a hardware issue.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git.exe -c usbasp -p m8a

avrdude_git.exe: error: program enable: target doesn't answer. 1
avrdude_git.exe: initialization failed, rc=-1
                 Double check connections and try again, or use -F to override
                 this check.


avrdude_git.exe done.  Thank you.

from usbasp.

As for the minimum ATmega8A USBASP clone, I will test it again. It came with very old usbasp FW and that is why I tried to upgrade.

All the atmega8a usbasp clones ( I have five, two of them doesn't have the rxd/txd pins exposed) work without a problem . Bad flashing maybe ?

You are right. It is a bad flashing. Using the tweezer properly fixed the issue.

from usbasp.

So I will close this issue as the last ATmega88 based USBISP v5.0 clone seems to have HW issues now -- I have flashed the other firmware (28-Feb-2022 usb composite FW and https://github.com/nerdralph/usbasp/blob/master/firmware/m88.hex) and results are the same.

Edit to add: the HW issue is identified -- not fixed yet. The ISP connector RST pin to the ATmega88 PB2 is broken. If I short them, the firmware works fine. So this is indeed a false alarm. Finally I soldered a jumper wire and now it works fine.

from usbasp.

@mcuee

If I don't ask too much, is it possible to test the libUSBUARTTerminal ( which is a GUI HID UART Terminal ) when you have some spare time ?

I'll appreciate the feedback .

from usbasp.

@mcuee

https://github.com/dioannidis/libUSBUARTTerminal/releases/tag/v0.7.1

Thx for your feedback

from usbasp.