rasteri wrote on 2024-05-20, 10:01:

So really you want a USB3 logic analyzer, USB2 might JUST work if the LA supports reducing channel count down to 2-3 (most will […]
Show full quote

So really you want a USB3 logic analyzer, USB2 might JUST work if the LA supports reducing channel count down to 2-3 (most will still stream 8 channels even if you disable some)

The logic analyzer I borrowed last week was a Saleae Logic Pro 16, it's great but it's a grand and half 🙁

Since I had to give it back, the one I'm currently using is this : Analyzing the ISA bus cheaply - it also works great but setting it up is a pain in the arse because support for that dev board hasn't been merged into sigrok yet. So you have to use a fork, which has sketchy reliability. Although someone has a more updated version of the fork here : https://github.com/danielkucera/libsigrok/tree/fx3 - maybe that works better (I should try it...)

The DSLogic U3Pro16 looks really good - although I'm not sure what it's software is like. Looks like there is some support for it in sigrok though - https://github.com/sigrokproject/libsigrok/pull/170

(sigrok support isn't essential, as long as the software can export the data somehow).

From what I can tell, the DSLogic software is itself a fork of sigrok/pulseview (and open source, on github), with more device-specific bells and whistles added. It can also export data, but it has a ton of protocol decoders already (presumably the same as in pulseview).

Did some more looking over the raw traces and I noticed something interesting, tinyUSB (and my PC, for that matter) sends exactly one packet per frame in a nice slow fashion - whereas hidman sends multiple packets per frame much quicker. I'm not sure if this is allowed by the USB standard. Perhaps the hub chip in your keyboard supports it but the keyboard controller chip doesn't.

Shouldn't be too hard to fix though.

EDIT : 🤣 yup. For the control endpoint you can't have more than one transfer per frame! I bet this is the problem...

Eivind wrote on 2024-05-20, 10:13:

stuff

OK I've pushed code to limit transfers to one per frame. It's prety quick-and-dirty but I think it should indicate if that's the issue or not

rasteri wrote on 2024-05-22, 01:35:

OK I've pushed code to limit transfers to one per frame. It's prety quick-and-dirty but I think it should indicate if that's the issue or not

Nice find, and I'm sure it doesn't hurt to keep it running within the official spec - but alas, it didn't fix my stubborn keyboard/hub combo... 🙁
Same debug output as before:

1reenumerating all ports
2port 0
3gdd ok 8
4mps 64
5addr ok 1
6gddfull ok 18
70x0409 0x005A 0x0100
8gcd ok 25
9
10Found hub
113 port hub
12new enum. 2
13checkn port 0
14ps- 0x101 pc- 0x01
15port 0 attached
16fullspeed
17gdd.fail
18enum.fail
19port 1
20gdd.fail

Eivind wrote on 2024-05-22, 07:22:

Nice find, and I'm sure it doesn't hurt to keep it running within the official spec - but alas, it didn't fix my stubborn keyboard/hub combo... 🙁

Oh bother. I'll have a look over some more LA logs to see what else is different but I'm starting to run out of ideas.

I did wonder if maybe the internal clock on the CH559 isn't accurate enough, perhaps I need to add an external crystal.

Either way I'd really need access to the keyboard to properly test it. Would you be perhaps willing to send it to me for a week or so? I'd pay postage and if anything happened to it I would of course replace it. I'll also chuck in a hidman AXP to say thanks! (or if you want anything else I have, like an LPC-to-ISA adapter, etc)

rasteri wrote on 2024-05-22, 08:37:

Oh bother. I'll have a look over some more LA logs to see what else is different but I'm starting to run out of ideas.

I did wonder if maybe the internal clock on the CH559 isn't accurate enough, perhaps I need to add an external crystal.

Either way I'd really need access to the keyboard to properly test it. Would you be perhaps willing to send it to me for a week or so? I'd pay postage and if anything happened to it I would of course replace it. I'll also chuck in a hidman AXP to say thanks! (or if you want anything else I have, like an LPC-to-ISA adapter, etc)

If you have any more ideas of things to try or ways I can help debug what's going on, I'd love to give that a shot first, as this keyboard is my daily driver. 😀
If we still come up short I'll send it to you, sure! I feel you're helping me at least as much as the other way round though, so I'd insist on paying for the postage.

With your recent fixes, did you end up having all your hubs work properly? Is it only my weird hub/keyboard that's causing problems at this point?

Eivind wrote on 2024-05-22, 10:30:

If you have any more ideas of things to try or ways I can help debug what's going on, I'd love to give that a shot first, as this keyboard is my daily driver. 😀
If we still come up short I'll send it to you, sure! I feel you're helping me at least as much as the other way round though, so I'd insist on paying for the postage.

With your recent fixes, did you end up having all your hubs work properly? Is it only my weird hub/keyboard that's causing problems at this point?

Yeah I should have said - I do still have quite a few other options to try, but the main reason I want to get physical access is so I don't have to keep bothering you to try new firmwares. If you're sure you're happy to keep trying then that's great!

And yes I actually do still have one hub that has issues on hidman but not on pico. It's a completely different kind of error (intermittent disconnect) but maybe it's related. I might try adding a crystal to see if that makes it stable...

rasteri wrote on 2024-05-22, 12:02:

Yeah I should have said - I do still have quite a few other options to try, but the main reason I want to get physical access is so I don't have to keep bothering you to try new firmwares. If you're sure you're happy to keep trying then that's great!

And yes I actually do still have one hub that has issues on hidman but not on pico. It's a completely different kind of error (intermittent disconnect) but maybe it's related. I might try adding a crystal to see if that makes it stable...

I'm not at all bothered by testing firmwares! If you still want to experiment and have me run tests on the HHKB, let's keep going! 😁
Btw, as mentioned before I'm also up for soldering on a uart connection to the chip and get debug info out that way, if it would help. And I do have a capable oscilloscope if you want me to do (or confirm) timing measurements.

Eivind wrote on 2024-05-22, 12:10:

I'm not at all bothered by testing firmwares! If you still want to experiment and have me run tests on the HHKB, let's keep going! 😁

Awesome! I usually assume everyone else's tolerance for boring debugging tasks is lower than mine...

Btw, as mentioned before I'm also up for soldering on a uart connection to the chip and get debug info out that way, if it would help. And I do have a capable oscilloscope if you want me to do (or confirm) timing measurements.

Actually... I've added a crystal to my dev board and that stabilizes my only remaining unstable hub. I was going to add a crystal to the final board anyway but I guess this cements the need!

So I might either ask you to bodge on a 12MHz crystal, or I could send you a pre-bodged hidman. Unfortunately it seems to break the PS/2 code somehow (it actually crashes if I enable the PS2 interrupt) so I'll need to figure out what's going on there first. Don't do anything yet, heh.

Eivind wrote on 2024-05-22, 12:10:

Btw, as mentioned before I'm also up for soldering on a uart connection to the chip and get debug info out that way, if it would help.

So it turns out it *isn't* actually crashing when running on a crystal, it's just that WCH in their infinite wisdom decided to make the bootloader switch the same pin as the crystal. So my code thinks you're holding the button so it goes into bootloader mode. If I disable the switch it works great on my stubborn hub.

If you're up for bodging on a crystal, it needs to go between pins 16 and 17. I also added two 10pf capacitors to ground.

To save you soldering to pin 16, you could solder to the switch instead - that's what I did (pic attached). Unfortunately there's no way around having to solder to pin 17, unless you broke it out on your tinyllama.

If you're not up for it, DM me and I'll send you a pre-bodged hidman 😀

And the code that enables the crystal (and disables the switch) is in the "crystal" branch on github.

rasteri wrote on 2024-05-22, 13:50:

So it turns out it *isn't* actually crashing when running on a crystal, it's just that WCH in their infinite wisdom decided to m […]
Show full quote

So it turns out it *isn't* actually crashing when running on a crystal, it's just that WCH in their infinite wisdom decided to make the bootloader switch the same pin as the crystal. So my code thinks you're holding the button so it goes into bootloader mode. If I disable the switch it works great on my stubborn hub.

If you're up for bodging on a crystal, it needs to go between pins 16 and 17. I also added two 10pf capacitors to ground.

To save you soldering to pin 16, you could solder to the switch instead - that's what I did (pic attached). Unfortunately there's no way around having to solder to pin 17, unless you broke it out on your tinyllama.

If you're not up for it, DM me and I'll send you a pre-bodged hidman 😀

And the code that enables the crystal (and disables the switch) is in the "crystal" branch on github.

I could probably desolder an smd 12 MHz crystal from one of my rp2040 projects and use that... But I'm curious - wouldn't disabling the switch make it impossible to do subsequent reflashes, if you can't get the chip into bootloader mode again?

Eivind wrote on 2024-05-22, 14:07:

I could probably desolder an smd 12 MHz crystal from one of my rp2040 projects and use that... But I'm curious - wouldn't disabling the switch make it impossible to do subsequent reflashes, if you can't get the chip into bootloader mode again?

If you hold the switch when you apply power it'll still work as a bootloader switch. It's only my code that I've removed it from (currently if you hold the button for 10sec it'll go to bootloader).

(I'll probably move the switch to P5.1 for the next hidman revision, having the oscillator trace run into a stub inside a switch is a signal integrity nightmare....)

EDIT : I am still looking for other problems though, if you don't want to add the crystal yet it's fine

I changed some stuff about transfer timings and merged the crystal code into main (OSC_EXTERNAL/ OSC_INTERNAL in makefile)

rasteri wrote on 2024-05-23, 14:37:

I changed some stuff about transfer timings and merged the crystal code into main (OSC_EXTERNAL/ OSC_INTERNAL in makefile)

Nice! Should I try adding the crystal at this point or are there other tweaks or fixes in the pipeline?

Eivind wrote on 2024-05-23, 14:49:

Nice! Should I try adding the crystal at this point or are there other tweaks or fixes in the pipeline?

I can't think of anything else at the moment. As far as I can tell, hidman is now behaving exactly the same as tinyusb.

Note that there's now no way to get into the debug mode since I've had to disable the button, but since it always fails at the same point, a simple go/no go test (after verifying it works with a previously working mouse/keyboard) will be fine.

You could maybe try the latest code before trying the crystal. You'll have to modify the makefile to use the internal oscillator, then modify it back if/when you want to try the crystal

rasteri wrote on 2024-05-23, 15:58:

I can't think of anything else at the moment. As far as I can tell, hidman is now behaving exactly the same as tinyusb.

Note that there's now no way to get into the debug mode since I've had to disable the button, but since it always fails at the same point, a simple go/no go test (after verifying it works with a previously working mouse/keyboard) will be fine.

You could maybe try the latest code before trying the crystal. You'll have to modify the makefile to use the internal oscillator, then modify it back if/when you want to try the crystal

Finally got to removing the 3225-size crystal and 0402 caps and managed to solder them together in a horribly messy way:

Flashed the latest firmware and ...drumroll.... it worked!! The HHKB connects (and re-connects) without issues! 😁 Awesome job, man! 🎉

Eivind wrote on 2024-05-25, 12:08:

Flashed the latest firmware and ...drumroll.... it worked!! The HHKB connects (and re-connects) without issues! 😁 Awesome job, man! 🎉

Alright!!! This is the best news I've had all month! (and my mum just had successful cancer surgery so you know how much this means to me 😜 )

Thank you so much for all your help mate, your seemingly endless supply of awkward keyboards/mice has massively improved hidman's compatibility.

The crystal just about fits on the board without doing too much re-routing. I've connected the button to pin 3.4, but I'll need to make sure there are no knock-on effects.

rasteri wrote on 2024-05-25, 13:08:

Eivind wrote on 2024-05-25, 12:08:

Flashed the latest firmware and ...drumroll.... it worked!! The HHKB connects (and re-connects) without issues! 😁 Awesome job, man! 🎉

Alright!!! This is the best news I've had all month! (and my mum just had successful cancer surgery so you know how much this means to me 😜 )

Sheesh, that's some kind of comparison! :p Hope she's doing well!

rasteri wrote on 2024-05-25, 13:08:

Thank you so much for all your help mate, your seemingly endless supply of awkward keyboards/mice has massively improved hidman's compatibility.

No problem, and as you know I want to use the HIDman again on another revision of the TinyLlama - so I still feel I'm the one who should be thanking you! 😀

rasteri wrote on 2024-05-25, 13:08:

The crystal just about fits on the board without doing too much re-routing. I've connected the button to pin 3.4, but I'll need to make sure there are no knock-on effects.

Cool! Very interested to know where you land the final pin setup. Also - for my application (using only PS/2, no serial), should I continue to use the BOARD_AXP variant? Are there any advantages to using the BOARD_PS2 one if I change the pin layout on my board?

Eivind wrote on 2024-05-25, 14:27:

Cool! Very interested to know where you land the final pin setup. Also - for my application (using only PS/2, no serial), should I continue to use the BOARD_AXP variant? Are there any advantages to using the BOARD_PS2 one if I change the pin layout on my board?

Makes no difference to be honest. Main reason I picked those pins is because they're the ones nearest the ports 😀 You could even make your own variant if you wanted to make routing easier.

Though possibly best to keep using the AXP pinout, it's the one that's likely to get the most testing going forward.

rasteri wrote on 2024-05-25, 15:04:

Eivind wrote on 2024-05-25, 14:27:

Cool! Very interested to know where you land the final pin setup. Also - for my application (using only PS/2, no serial), should I continue to use the BOARD_AXP variant? Are there any advantages to using the BOARD_PS2 one if I change the pin layout on my board?

Makes no difference to be honest. Main reason I picked those pins is because they're the ones nearest the ports 😀 You could even make your own variant if you wanted to make routing easier.

Though possibly best to keep using the AXP pinout, it's the one that's likely to get the most testing going forward.

I'd prefer to stick with one of your default variants, to avoid having to maintain a separate branch or whatever. AXP it is, then!
About the button - if you decide to move it to 3.4, you'd still need to keep some kind of way to short 4.6 to ground for bootloader mode, right...?