search

dioannidis / usbasp

usbasp improved firmware
GNU General Public License v2.0
73 stars 12 forks source link

Firmware does not work on some USBISP clone with ATmega88 #11

Closed mcuee closed 2 years ago

mcuee commented 2 years ago

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

dioannidis commented 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 ?

dioannidis commented 2 years ago

Maybe it's related with this https://github.com/aleh/usbisp/issues/6#issuecomment-719816915

I'll try it tonight

mcuee commented 2 years ago

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.

mcuee commented 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 ?

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 usbisp_m88_v5

mcuee commented 2 years ago

@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.

dioannidis commented 2 years ago

@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 ?

mcuee commented 2 years ago

The failed device does not enumerate.

dioannidis commented 2 years ago

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

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

mcuee commented 2 years ago

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

mcuee commented 2 years ago

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.

mcuee commented 2 years ago

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)
mcuee commented 2 years ago

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. usbasp_m8a_minimum

dioannidis commented 2 years ago

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 ....

dioannidis commented 2 years ago

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

mcuee commented 2 years ago

@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).

mcuee commented 2 years ago

@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.

dioannidis commented 2 years ago

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 ?

dioannidis commented 2 years ago

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 ....

mcuee commented 2 years ago

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.

mcuee commented 2 years ago

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.
mcuee commented 2 years ago

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.

mcuee commented 2 years ago

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.

mcuee commented 2 years ago

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
mcuee commented 2 years ago

@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.

dioannidis commented 2 years ago

@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 .

mcuee commented 2 years ago

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.

  1. The label lblMonitor should be removed.

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

dioannidis commented 2 years ago

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 .

dioannidis commented 2 years ago

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.

mcuee commented 2 years ago

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).

mcuee commented 2 years ago

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.

dioannidis commented 2 years ago

@mcuee

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

Thx for your feedback