Tasoller custom firmware not working "unsupported device"

[icex2]

Copy-paste from chat with CrazyRedMachine on discord

hi, I saw the tasollertools repo and something caught my attention, maybe I might have a fix for the incompatible chipset issue but I know noone who could test it lol
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00ff  1x 255 bytes
        bInterval               1

wMaxPacketSize is out of spec (can either be 8 16 32 64 for fullspeed, or only 512 for highspeed)
and most importantly, looking at host.bin in the firmware files, you see that it isn't even 00 ff in the config descriptor (look for "01 07 05 03 02" with a hex editor and you'll see the rest of the descriptor), it's "07 05 03 02 00 04" which is a wMaxPacketSize of 1024 lol
idk if there are crc checks in the firmware files or not, but changing that 0x04 byte back to a 0x02 for 512 should fix the usb config descriptor, and hopefully would solve the "unsupported device" issues

[icex2]

i don't have any possibility to test this since i sold my tasoller some time ago.

if anyone else can test it and confirm this is fixing the issue, i am happy to accept a merge request with the patched firmware.

[icex2]

In GitLab by @akiroz on Jan 26, 2022, 22:23

I can confirm that wMaxPacketSize is indeed 1024 when poking around with the WinUSB API. However, I don't have a USB host controller that's incompatible to reproduce the issue.

[icex2]

In GitLab by @shtokopep on Jan 30, 2022, 01:13

A friend of mine still has his tasoller and the unsupported device bug when plugging into the usb 2.0 ports of his motherboard (not sure if that's supposed to be supported in the first place), and after a little bit of testing :

• setting wMaxPacketSize to 512 didn't solve the issue
• setting wMaxPacketSize to 64 did solve the issue, however the leds were working only on part of the panel

cross-referencing akiroz' bitmaps, it looked like the led transfer was indeed truncated to the 64 first bytes, which made me investigate their chuniio.dll a little...

they use the libusb asynchronous I/O (with a call to libusb_fill_bulk_transfer ) but their callback function doesn't take the rearm into account (since we're sending more data (240 bytes) than the endpoint size (64 bytes), it will require 4 different transfers and the callback function is then supposed to take care of tracking whether there are still more bytes to send).

I'll write the patch, get my friend to test and prepare a PR

[icex2]

In GitLab by @shtokopep on Jan 31, 2022, 01:29

My patch to chuniio.dll seems to be working correctly in terms of packet handling, however it didn't fix the issue.

I then wrote a small test app (just sending red/green/blue/white to the panel) using libusb synchronous I/O to have a simple test case, and it exhibits the same problem (first 26 keys working fine, last 6+sides not working, see attached picture) even though libusb tells me it succesfully wrote 240 bytes.

I think while 240 bytes are indeed sent to the endpoint, the device firmware is not able to correctly reconstruct the data packet (maybe the wrong endpoint size is also hardcoded elsewhere in the transfer handling routine, but i'm not gonna look for other occurrences of a single byte lol)

On a more positive note, I've noticed that the device advertises itself as a full speed device in the device descriptor rather than high (in fact I learnt that a size of 1024 does exist for superspeed, but this also requires BOS descriptors which the tasoller doesn't have...), and it also reports an interval polling rate which should be 0 for bulk endpoints (technically it's ignored, but I've had enumeration issues with some microcontrollers for this exact reason before) so there's hope that this is the reason why it was still failing to enumerate.

TL;DR I spent a little while patching chuniio.dll for nothing, but I've got another lead on a firmware patch, will report back soon

[icex2]

Great work. Looking forward to that patch.

[icex2]

In GitLab by @shtokopep on Feb 3, 2022, 12:34

mmhh, after more attempts, unfortunately nothing worked.. interestingly enough, the mcu inside seems to be a NUC140 according to akiroz ( "It's likely an NUC140, the DFU manufacturer says "SS140" and the QFP48 pinout matches with the crystal and USB pins" )

if that's the case then the mcu is actually only capable of fullspeed usb, not highspeed/superspeed, which might explain why I still saw it enumerated as full speed and why it's up to the chipset to accept fullspeed with an endpoint packet size of 512+ despite it being out of spec.

the next step would be to properly implement either the high speed "other speed descriptor" (which might probably only cause more issues if mcu is not capable of high speed anyways), or fix the packet reading behavior so that fragmented packets can be reconstructed as they should... however both of these solutions would require firmware disassembly and more time than I'd like to spend on it :p

Therefore I've decided to send an email to dao support instead, as the fix would be trivial for them if they know what they need to change in the firmware. Hopefully they will listen

[icex2]

that's unfortunate, but thanks for digging and giving a summary about it. FYI that i tried to reach out to dao about this issue quite a while ago and didn't get an answer, unfortunately. maybe the result is different this time. keep us posted.