Eivind wrote on 2024-05-14, 19:39:

I don't have the two UART0 pins connected to anything on the TL 2.1 (pins 7 and 4, right?). I could always solder on something if needed, but if it's relatively simple for you to make a fw version that spits out relevant info on the PS/2 keyb lines, that would be easier for me! 😜

OK latest commit has hub info in the debug output.

Note that if you haven't used the menu in a while the process has changed - you have to hold down the button for a few seconds to make the menu appear.

Also pressing the button without holding it will cycle through AT/XT/Amstrad modes so be careful!

rasteri wrote on 2024-05-14, 20:57:

OK latest commit has hub info in the debug output.

Note that if you haven't used the menu in a while the process has changed - you have to hold down the button for a few seconds to make the menu appear.

Also pressing the button without holding it will cycle through AT/XT/Amstrad modes so be careful!

Thanks!

Here's what was printed after starting the HID logging, unplugging the working direct-attached keyboard and plugging in the HHKB keyboard/hub:

1Found hub
23 port hub
3ps- 0x101 pc- 0x01
4port 0 attached
5fullspeed
6enum.fail
7ps- 0x100 pc- 0x00
8ps- 0x100 pc- 0x00

Eivind wrote on 2024-05-14, 21:14:

Here's what was printed after starting the HID logging, unplugging the working direct-attached keyboard and plugging in the HHKB […]
Show full quote

Here's what was printed after starting the HID logging, unplugging the working direct-attached keyboard and plugging in the HHKB keyboard/hub:

Copy code to clipboard

1fullspeed

Aha, as we suspected it's a fullspeed device therefore won't be susceptible to the lowspeed issue. So there's no reason why your HHKB shouldn't work on the hidman if it works on other USB1.1 hosts (your RP2040). I suspect that is a bug in hidman.

BTW, I've tested your RP2040 code on a pico board and it has the exact same issue as hidman/my old pc with lowspeed devices on USB2 hubs. So good news, the lowspeed issue isn't because of a bug in hidman. Bad news, I suppose we'll just have to accept that certain hub and device combinations won't work.

Anyway, the latest commit dumps even more hub debugging info to the keyboard. If you could grab me a dump of your HHKB again that would be great. Maybe do it 3-4 times just to see if it's failing in the same place each time.

rasteri wrote on 2024-05-15, 19:57:

Aha, as we suspected it's a fullspeed device therefore won't be susceptible to the lowspeed issue. So there's no reason why your HHKB shouldn't work on the hidman if it works on other USB1.1 hosts (your RP2040). I suspect that is a bug in hidman.

BTW, I've tested your RP2040 code on a pico board and it has the exact same issue as hidman/my old pc with lowspeed devices on USB2 hubs. So good news, the lowspeed issue isn't because of a bug in hidman. Bad news, I suppose we'll just have to accept that certain hub and device combinations won't work.

Yeah, that's something we can live with I suppose!

rasteri wrote on 2024-05-15, 19:57:

Anyway, the latest commit dumps even more hub debugging info to the keyboard. If you could grab me a dump of your HHKB again that would be great. Maybe do it 3-4 times just to see if it's failing in the same place each time.

Here's the dump from the latest firmware, I ran it 4 times and checked that it was identical each time:

1gdd ok 8
2mps 64
3addr ok 1
4gddfull ok 18
50x0409 0x005A 0x0100
6gcd ok 25
7
8Found hub
93 port hub
10ps- 0x101 pc- 0x01
11port 0 attached
12fullspeed
13gdd.fail
14enum.fail
15ps- 0x100 pc- 0x00
16ps- 0x100 pc- 0x00

Eivind wrote on 2024-05-15, 20:41:

Here's the dump from the latest firmware, I ran it 4 times and checked that it was identical each time:

Oh interesting, looks like it's just not able to speak to the device at all. My crappy hubs fail much later in the process.

I had a look through the tinyUSB code and it looks like the only major thing it's doing differently is retrying the enumeration process several times if it fails. Apparently this is needed because some devices glitch out when power is first applied.

Because hidman re-enumerates ALL ports every time you add a device, you can force the enumeration process by connecting a second device to hidman.

So can you try this - put the hidman in debug dump mode as before, then connect your HHKB (it'll fail), then connect a second device to the other CH559 USB port and see if that wakes up the HHKB?

Thanks for all your help.

(if this doesn't work I'll spin a new version of the code that JUST retries enumeration of the hub ports, rather than everything).

rasteri wrote on 2024-05-16, 10:47:

Oh interesting, looks like it's just not able to speak to the device at all. My crappy hubs fail much later in the process. […]
Show full quote

Oh interesting, looks like it's just not able to speak to the device at all. My crappy hubs fail much later in the process.

I had a look through the tinyUSB code and it looks like the only major thing it's doing differently is retrying the enumeration process several times if it fails. Apparently this is needed because some devices glitch out when power is first applied.

Because hidman re-enumerates ALL ports every time you add a device, you can force the enumeration process by connecting a second device to hidman.

So can you try this - put the hidman in debug dump mode as before, then connect your HHKB (it'll fail), then connect a second device to the other CH559 USB port and see if that wakes up the HHKB?

Thanks for all your help.

(if this doesn't work I'll spin a new version of the code that JUST retries enumeration of the hub ports, rather than everything).

Didn't seem to do anything new with the HHKB once I plugged in another device (a logitech keyboard).
Here's the log - I added comments in parentheses:

1Logging HID Data. Press ESC to stop...
2I0 L8- 0 0 0 0 0 0 0 0 
3(remove logitech keyboard)
4(plug in logitech keyboard)
5gdd ok 8
6mps 8
7addr ok 1
8gddfull ok 18
90x046D 0xC30E 0x0180
10gcd ok 59
11
12
13Interface 0 Report Descriptor - 
14
1505 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01 
1675 01 95 08 81 02 95 01 75 08 81 01 95 03 75 01 
1705 08 19 01 29 03 91 02 95 05 75 01 91 01 95 06 
1875 08 26 FF 00 05 07 19 00 29 91 81 00 C0 
19
20
21
22Interface 1 Report Descriptor - 
23
2405 0C 09 01 A1 01 85 01 15 01 26 5E 00 75 08 95 
2502 0A 25 02 09 B6 09 B5 09 B7 09 CD 09 EA 09 E9 
2609 E2 0A 92 01 0A 8A 01 0A 21 02 0A 23 02 0A 2A 
2702 0A 24 02 0A 83 01 1B 01 00 09 00 2B 4C 00 09 
2800 05 0C 0A 27 02 0A 26 02 09 B8 81 60 C0 05 01 
2909 80 A1 01 85 02 15 01 25 03 75 02 95 01 09 82 
3009 81 09 83 81 60 75 06 81 03 C0 
31
32(remove logitech keyboard)
33(plug in HHKB)
34gdd ok 8
35mps 64
36addr ok 1
37gddfull ok 18
380x0409 0x005A 0x0100
39gcd ok 25
40
41Found hub
423 port hub
43ps- 0x101 pc- 0x01
44port 0 attached
45fullspeed
46gdd.fail
47enum.fail
48ps- 0x100 pc- 0x00
49ps- 0x100 pc- 0x00
50(plug in logitech keyboard)
51gdd ok 8
52mps 8
53addr ok 6
54gddfull ok 18
550x046D 0xC30E 0x0180
56gcd ok 59
57
58
59Interface 0 Report Descriptor - 
60

6105 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01 
6275 01 95 08 81 02 95 01 75 08 81 01 95 03 75 01 
6305 08 19 01 29 03 91 02 95 05 75 01 91 01 95 06 
6475 08 26 FF 00 05 07 19 00 29 91 81 00 C0 
65
66
67
68Interface 1 Report Descriptor - 
69
7005 0C 09 01 A1 01 85 01 15 01 26 5E 00 75 08 95 
7102 0A 25 02 09 B6 09 B5 09 B7 09 CD 09 EA 09 E9 
7209 E2 0A 92 01 0A 8A 01 0A 21 02 0A 23 02 0A 2A 
7302 0A 24 02 0A 83 01 1B 01 00 09 00 2B 4C 00 09 
7400 05 0C 0A 27 02 0A 26 02 09 B8 81 60 C0 05 01 
7509 80 A1 01 85 02 15 01 25 03 75 02 95 01 09 82 
7609 81 09 83 81 60 75 06 81 03 C0 

Eivind wrote on 2024-05-16, 11:05:

Didn't seem to do anything new with the HHKB once I plugged in another device (a logitech keyboard).

Damn sorry, there's a bit of code that detects if a device is already enumerated and won't enumerate it again.

Latest commit fixes it and has a new feature - if you press the button it will enumerate all ports/devices, no need to re-plug anything (you'll need to be in HID dump mode as before)

You might have to do the re-enumeration 3 or 4 times to get it to detect, one of my hubs does that as it turns out...

rasteri wrote on 2024-05-16, 20:43:

Damn sorry, there's a bit of code that detects if a device is already enumerated and won't enumerate it again. […]
Show full quote

Eivind wrote on 2024-05-16, 11:05:

Didn't seem to do anything new with the HHKB once I plugged in another device (a logitech keyboard).

Damn sorry, there's a bit of code that detects if a device is already enumerated and won't enumerate it again.

Latest commit fixes it and has a new feature - if you press the button it will enumerate all ports/devices, no need to re-plug anything (you'll need to be in HID dump mode as before)

You might have to do the re-enumeration 3 or 4 times to get it to detect, one of my hubs does that as it turns out...

Forcing re-enumeration by pressing the button works fine, but apparently the HHKB is only detected every other time. Still fails as before, though.
Here's a new log, my comments inserted in parentheses as before:

1HIDMAN v0.1 Main Menu
2
31. Adv.Keyboard - No
42. Adv.Mouse - No
53. Intellimouse - No
6
78. Log HID Data
89. Dump PS2 mouse status
9ESC to exit menu
10
11Logging HID Data. Press ESC to stop...
12I0 L8- 0 0 0 0 0 0 0 0
13
14(removing logitech keyboard)
15(plugging in HHKB)
16
17reenumerating all ports
18port 0
19gdd.fail
20port 1
21gdd ok 8
22mps 64
23addr ok 6
24gddfull ok 18
250x0409 0x005A 0x0100
26gcd ok 25
27
28Found hub
293 port hub
30ps- 0x101 pc- 0x01
31port 0 attached
32fullspeed
33gdd.fail
34enum.fail
35ps- 0x100 pc- 0x00
36ps- 0x100 pc- 0x00
37
38(clicking button)
39
40reenumerating all ports
41port 0
42gdd.fail
43port 1
44gdd.fail
45
46(clicking button)
47
48reenumerating all ports
49port 0
50gdd.fail
51port 1
52gdd ok 8
53mps 64
54addr ok 6
55gddfull ok 18
560x0409 0x005A 0x0100
57gcd ok 25
58
59Found hub
603 port hub

61ps- 0x101 pc- 0x01
62port 0 attached
63fullspeed
64gdd.fail
65enum.fail
66ps- 0x100 pc- 0x00
67ps- 0x100 pc- 0x00
68
69(clicking button)
70
71reenumerating all ports
72port 0
73gdd.fail
74port 1
75gdd.fail
76
77(clicking button)
78
79reenumerating all ports
80port 0
81gdd.fail
82port 1
83gdd ok 8
84mps 64
85addr ok 6
86gddfull ok 18
870x0409 0x005A 0x0100
88gcd ok 25
89
90Found hub
913 port hub
92ps- 0x101 pc- 0x01
93port 0 attached
94fullspeed
95gdd.fail
96enum.fail
97ps- 0x100 pc- 0x00
98ps- 0x100 pc- 0x00
99
100(clicking button)
101
102reenumerating all ports
103port 0
104gdd.fail
105port 1
106gdd.fail
107
108(clicking button)
109
110reenumerating all ports
111port 0
112gdd.fail
113port 1
114gdd ok 8
115mps 64
116addr ok 6
117gddfull ok 18
1180x0409 0x005A 0x0100
119gcd ok 25
120
121Found hub
1223 port hub
123ps- 0x101 pc- 0x01
124port 0 attached
125fullspeed
126gdd.fail
127enum.fail
128ps- 0x100 pc- 0x00
129ps- 0x100 pc- 0x00
130
131(clicking button)
132
133reenumerating all ports
134port 0
135gdd.fail
136port 1
137gdd.fail
138
139(clicking button)
140
141reenumerating all ports
142port 0
143gdd.fail
144port 1
145gdd ok 8
146mps 64
147addr ok 6
148gddfull ok 18
1490x0409 0x005A 0x0100
150gcd ok 25
151
152Found hub
1533 port hub
154ps- 0x101 pc- 0x01
155port 0 attached
156fullspeed
157gdd.fail
158enum.fail
159ps- 0x100 pc- 0x00
160ps- 0x100 pc- 0x00

Eivind wrote on 2024-05-16, 21:04:

Forcing re-enumeration by pressing the button works fine, but apparently the HHKB is only detected every other time. Still fails as before, though.

Hmm that's unfortunate.

Thankfully I now have a pico with tinyUSB to compare it to, so I'll get the logic analyzer out and compare its power/reset sequencing with what hidman does.

(BTW I've actually got tinyUSB to compile in sdcc. I suspect by the time I've got everything working it's not going to fit in the CH559's memory, but we'll see).

rasteri wrote on 2024-05-17, 00:29:

Thankfully I now have a pico with tinyUSB to compare it to, so I'll get the logic analyzer out and compare its power/reset sequencing with what hidman does.

Sounds difficult, but I have very little experience using LAs 😀 Do you have one with built-in support for decoding all sorts of USB protocol things?

rasteri wrote on 2024-05-17, 00:29:

(BTW I've actually got tinyUSB to compile in sdcc. I suspect by the time I've got everything working it's not going to fit in the CH559's memory, but we'll see).

oooh, that's interesting! Maybe it's possible to strip out stuff not needed for this project from the stack, like the whole Device sub-stack...?

Eivind wrote on 2024-05-17, 06:17:

Sounds difficult, but I have very little experience using LAs 😀 Do you have one with built-in support for decoding all sorts of USB protocol things?

It's actually not too hard, it can output pcap format that imports right into wireshark so it's pretty easy to read. As I've been familiarizing myself with tinyUSB I've noticed some other stuff my (or rather WCH's) USB code doesn't do so maybe it'll be something simple.

oooh, that's interesting! Maybe it's possible to strip out stuff not needed for this project from the stack, like the whole Device sub-stack...?

Yeah certainly a lot of stuff will need to be stripped out (an initial attempt to link the code used 80KB...). There are also sections of code that push a lot of stuff on the stack, which is not ideal on a device with 256 byte stack. I still don't think it's feasible to do a complete port, but porting just the USB enumeration stuff and leaving the rest of my code to do the low level stuff is likely possible.

BTW do you know what USB hub chip your keyboard uses? I can maybe find a hub that uses the same chip to test. (I ain't spending $100s on a keyboard with half the keys missing 🤣 )

rasteri wrote on 2024-05-17, 10:06:

It's actually not too hard, it can output pcap format that imports right into wireshark so it's pretty easy to read. As I've been familiarizing myself with tinyUSB I've noticed some other stuff my (or rather WCH's) USB code doesn't do so maybe it'll be something simple.

Nice!

rasteri wrote on 2024-05-17, 10:06:

Yeah certainly a lot of stuff will need to be stripped out (an initial attempt to link the code used 80KB...). There are also sections of code that push a lot of stuff on the stack, which is not ideal on a device with 256 byte stack. I still don't think it's feasible to do a complete port, but porting just the USB enumeration stuff and leaving the rest of my code to do the low level stuff is likely possible.

Yeah, maybe that's something worth looking into!

rasteri wrote on 2024-05-17, 10:06:

BTW do you know what USB hub chip your keyboard uses? I can maybe find a hub that uses the same chip to test. (I ain't spending $100s on a keyboard with half the keys missing 🤣 )

Haha yeeeeah, it's not for everyone. I think I've spent like $400 for mine, it's got extra dampening rings and pads and lubed key stems and whatnot. Makes it extremely nice to type on, with satisfyingly deep and fat thock-sounds... 😁
I'll open her up and see what's inside!

Here's the USB hub chip:

From what I can tell, it's a NEC μPD720114 (datasheet).

Edit: btw, nice silkscreen - unusually clear and with helpful arrows where needed. Topre knew what they were doing... 😌

Eivind wrote on 2024-05-17, 10:46:

NEC μPD720114

Thanks for finding that out. Hopefully I can find another hub with the same chip, or even order the chip myself and build a lil USB hub...

Meantime I'm poring over logic analyzer logs. I've seen a few differences during device reset that could perhaps affect it.

Failing that, I had another idea for how we could debug this without you having a logic analyzer - I could modify your RP2040 code to printf info about the USB enumeration process. ITXllama has access to UART0 of the RP2040 yeah?

rasteri wrote on 2024-05-17, 12:20:

Thanks for finding that out. Hopefully I can find another hub with the same chip, or even order the chip myself and build a lil USB hub...

Meantime I'm poring over logic analyzer logs. I've seen a few differences during device reset that could perhaps affect it.

Failing that, I had another idea for how we could debug this without you having a logic analyzer - I could modify your RP2040 code to printf info about the USB enumeration process. ITXllama has access to UART0 of the RP2040 yeah?

Yep, I routed the default uart tx to pin 12 (add_compile_definitions(PICO_DEFAULT_UART_TX_PIN=12) in CMakeLists.txt), which goes to a pin header. I've used that to look at printfs before.

Eivind wrote on 2024-05-17, 13:25:

Yep, I routed the default uart tx to pin 12 (add_compile_definitions(PICO_DEFAULT_UART_TX_PIN=12) in CMakeLists.txt), which goes to a pin header. I've used that to look at printfs before.

I just did some playing with the rp2040 again. If you set CFG_TUSB_DEBUG to 3 in tusb_config.h then the output of that will likely contain everything I need.

Thanks again!

Hello everyone!
Is this thing ever going to be available for purchase fully assembled?

SPiKA85 wrote on 2024-05-17, 20:28:

Hello everyone!
Is this thing ever going to be available for purchase fully assembled?

Yeah I'm in the middle of getting a batch made up. Watch this space.

rasteri wrote on 2024-05-17, 13:38:

I just did some playing with the rp2040 again. If you set CFG_TUSB_DEBUG to 3 in tusb_config.h then the output of that will likely contain everything I need.

Thanks again!

Debug level 3 was insanely busy, I got over 800 lines when plugging in the HHKB 😁
I've attached both a level 2 and 3 log of plugging the HHKB into the native USB port of the rp2040.
Excited to see if you can make sense of any of this!

Eivind wrote on 2024-05-18, 10:31:

Excited to see if you can make sense of any of this!

Yup this is perfect! Thanks!

Main difference I noticed so far is that hidman proactively checks each hub port for devices during enumeration, whereas tinyusb just powers each port on and then waits for the hub itself to send a change interrupt. Maybe your hub chip or keyboard takes a while to wake up. I'll modify hidman so it does the same thing as tinyusb (which will also give us the ability to hotplug USB hub devices - it's a feature I had started working on in another branch anyway)

One of my hubs that intermittently fails actually does the same thing : (hidman on left, tinyusb on right)