Closed mcuee closed 2 years ago
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 ?
Maybe it's related with this https://github.com/aleh/usbisp/issues/6#issuecomment-719816915
I'll try it tonight
I do not think it is the same as https://github.com/aleh/usbisp/issues/6#issuecomment-719816915 because your code has already leave Port D as input.
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
@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.
@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 ?
The failed device does not enumerate.
Unfortunately I don't have a similar device to test .
Just ordered some from here but they'll take some time to arrive .
Thanks. Take your time. Anyway, I have alternative working FW for those two units.
BTW, there is a version 6 PCB using ATmega88p. You may want to add support for that one as well.
Edit: most likely this already works.
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)
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.
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 ....
@mcuee Is it possible to use wireshark ( or something similar ) to log the enumeration process ?
@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).
@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.
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 ?
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 ....
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.
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.
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.
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.
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
@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.
@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 .
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.
The label lblMonitor
should be removed.
The About
menu item now shows nothing. Probably a simple program verson and copyright notice should be there.
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 .
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.
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).
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 here:
I have three "USB ISP Version 2.0" devices (marked "MX-U2BLSP-V5.00" on the PCB). I think the marking on the PCB is a typo, they mean to say "MX-USBISP-V5.00".
Only one of them works with the USB Composite FW here. But they all work with the FW here. https://github.com/MCUdude/usbisp