rasteri wrote on 2024-05-18, 11:29:

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)

Nice, fingers crossed! 😁

Eivind wrote on 2024-05-18, 12:03:

Nice, fingers crossed! 😁

Okay, latest commit uses the change request endpoint instead of manual polling. Interested to see if this makes any difference.

rasteri wrote on 2024-05-18, 23:05:

Okay, latest commit uses the change request endpoint instead of manual polling. Interested to see if this makes any difference.

Tried flashing the newest fw and got nothing when tapping the keys on my known-working keyboard. Then I reflashed an older fw, and still nothing.
Looks like I've done something to the hardware by accident. Though, I can't for the life of me figure out what it is, I've checked and rechecked for continuity everywhere between the SOM pins and the CH559 chip - and the chip programs and verifies just fine, so doesn't look like errors between the USB port and the chip either. I even found another SOM and switched to that, still nothing. I think I need to sleep on this, maybe see if I can find another TinyLlama board tomorrow... :p

Eivind wrote on 2024-05-19, 00:43:

Tried flashing the newest fw and got nothing when tapping the keys on my known-working keyboard. Then I reflashed an older fw, and still nothing.

Weird. You doing a "make clean" between firmware compiles? Make doesn't automatically scan header files for changes and that's caused me problems in the past

rasteri wrote on 2024-05-19, 08:41:

Weird. You doing a "make clean" between firmware compiles? Make doesn't automatically scan header files for changes and that's caused me problems in the past

Yes, I always do a "make clean" before "make". I did figure out what was wrong - the chip wasn't programmed properly. The two WCHISPTool options "Clear DataFlash" and "Clear CodeFlash" was disabled, when I enabled these before programming, it started working again with my simple keyboard.
Unfortunately, the HHKB still refuses to cooperate. Here's the log of it being plugged in using the newest firmware:

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

Happy to run another firmware that dumps way more debug info, if that could be of help?
I don't know if it makes any difference whether to log debug stuff over PS/2 or out of the uart - if the latter is easier or more capable, I can also try to solder on a wire directly to one of the chip's legs?

Eivind wrote on 2024-05-19, 10:09:

Happy to run another firmware that dumps way more debug info, if that could be of help?
I don't know if it makes any difference whether to log debug stuff over PS/2 or out of the uart - if the latter is easier or more capable, I can also try to solder on a wire directly to one of the chip's legs?

It's OK, let me regroup and I'll figure out what the next step is. I'll do some more looking over your tinyusb logs and compare captures on my hubs.

I notice that the raspberry pi pico can be used as a logic analyzer - I'll do some testing to see if it's fast enough to capture USB. I'm guessing you have access to a pico or two, maybe getting you to probe the USB data lines would be the next step.

I'll be in touch soon.

rasteri wrote on 2024-05-19, 11:19:

It's OK, let me regroup and I'll figure out what the next step is. I'll do some more looking over your tinyusb logs and compare captures on my hubs.

I notice that the raspberry pi pico can be used as a logic analyzer - I'll do some testing to see if it's fast enough to capture USB. I'm guessing you have access to a pico or two, maybe getting you to probe the USB data lines would be the next step.

I'll be in touch soon.

I have a ton of picos! 😀 But speaking of LAs, I believe I do in fact have a Hantek 4032L lying around somewhere as well. Not sure it's capable of USB 2.0 capturing, and I seem to recall the software situation was pretty rough, but it might be worth a shot...

Eivind wrote on 2024-05-19, 11:28:

I have a ton of picos! 😀 But speaking of LAs, I believe I do in fact have a Hantek 4032L lying around somewhere as well. Not sure it's capable of USB 2.0 capturing, and I seem to recall the software situation was pretty rough, but it might be worth a shot...

Oh - sikrok/pulseview supports the Hantek 4032L. That's the same software my LA uses. That would be ideal if you can get that to work.

The 4032L can do 400MHz apparently. I don't need the capture that fast but 200MHz will be more than enough. Give me a shout if you need help setting it up.

The Pico looks good but it's limited by tiny memory and only a USB/1.1 output. (I'll still try it though, it would be useful in general)

rasteri wrote on 2024-05-19, 11:36:

Oh - sikrok/pulseview supports the Hantek 4032L. That's the same software my LA uses. That would be ideal if you can get that to work.

The 4032L can do 400MHz apparently. I don't need the capture that fast but 200MHz will be more than enough. Give me a shout if you need help setting it up.

The Pico looks good but it's limited by tiny memory and only a USB/1.1 output. (I'll still try it though, it would be useful in general)

Did a reasonably thorough search through my electronics stash in the basement, couldn't find the Hantek! 🙁 I know I haven't thrown it out though, so it must be down there somewhere. It's been like 5 years or so since I last used it. Is it even remotely viable to try the pico in this particular situation? I suppose I could turn the basement upside down looking for the Hantek, but I'd like to know what my options are first... 😉

Eivind wrote on 2024-05-19, 12:24:

Did a reasonably thorough search through my electronics stash in the basement, couldn't find the Hantek! 🙁 I know I haven't thrown it out though, so it must be down there somewhere. It's been like 5 years or so since I last used it. Is it even remotely viable to try the pico in this particular situation? I suppose I could turn the basement upside down looking for the Hantek, but I'd like to know what my options are first... 😉

Yeah I'm testing the pico as we speak. I'll let you know!

rasteri wrote on 2024-05-19, 12:27:

Eivind wrote on 2024-05-19, 12:24:

Did a reasonably thorough search through my electronics stash in the basement, couldn't find the Hantek! 🙁 I know I haven't thrown it out though, so it must be down there somewhere. It's been like 5 years or so since I last used it. Is it even remotely viable to try the pico in this particular situation? I suppose I could turn the basement upside down looking for the Hantek, but I'd like to know what my options are first... 😉

Yeah I'm testing the pico as we speak. I'll let you know!

Awesome! I'm sure you're aware, but keep in mind the pico can be heavily overclocked, if that's helpful in getting higher capture speeds.

Eivind wrote on 2024-05-19, 12:54:

Awesome! I'm sure you're aware, but keep in mind the pico can be heavily overclocked, if that's helpful in getting higher capture speeds.

The difficulty isn't about the frequency of capture, it's about getting the data back to the PC for analysis. Pico only has USB1.1 so we can only get so much stuff back.

I can only get it to dump about 200ms of USB data, which isn't really long enough. Looks like the pico ain't gonna work 🙁

Anyway, no need to go searching for your hantek yet - I'll do some more reading over your logs. I might notice something else different.

Eivind wrote on 2024-05-19, 12:54:

Yeah I'm testing the pico as we speak. I'll let you know!

Aha I've found a crucial difference - hidman clears the port reset state instead of clearing the change register. That's definitely a bug. Maybe your keyboard doesn't finish resetting before hidman clears the reset state?

Anyway I've fixed it in the latest commit. Let me know if that makes any difference.

rasteri wrote on 2024-05-19, 20:29:

Aha I've found a crucial difference - hidman clears the port reset state instead of clearing the change register. That's definitely a bug. Maybe your keyboard doesn't finish resetting before hidman clears the reset state?

Anyway I've fixed it in the latest commit. Let me know if that makes any difference.

No difference, I'm afraid. 🙁
I did do another search for the Hantek, but no luck. Must have put it someplace clever, and not together with my other electronics stuff for some reason.
Shame about the Pico... 🙁 Did it support RLE, to compress the data and be able to fit more?

Hah, found the Hantek LA in the place I least expected it to be (which is why I finally looked there). The power supply wasn't there though (horrible barrel-plug center-negative thing edit: i'm blind, it's regular center-positive), but I read you should be able to mod it to draw power from the USB port...

EDIT: that worked perfectly, I have the device powered up and connected to pulseview. Let me know how I should set up pulseview and wire up the probes, and I'll try to do a capture!

Eivind wrote on 2024-05-19, 22:26:

EDIT: that worked perfectly, I have the device powered up and connected to pulseview. Let me know how I should set up pulseview and wire up the probes, and I'll try to do a capture!

Awesome!

I don't know what options your logic analyzer has, but I just need you to probe the D+ and D- USB lines (also ground). I need a capture frequency of around 200MHz ideally, and you probably want to disable all the unused channels in pulseview. Then start the capture, and then connect your keyboard.

If it's possible to get both hidman and tinyusb captures that would be great.

Just save it as a standard .sr file and post it, it should only be a couple megabytes hopefully. No need to set up protocol decoders or anything, I can do that at my end.

thanks again!

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

Awesome! […]
Show full quote

Awesome!

I don't know what options your logic analyzer has, but I just need you to probe the D+ and D- USB lines (also ground). I need a capture frequency of around 200MHz ideally, and you probably want to disable all the unused channels in pulseview. Then start the capture, and then connect your keyboard.

If it's possible to get both hidman and tinyusb captures that would be great.

Just save it as a standard .sr file and post it, it should only be a couple megabytes hopefully. No need to set up protocol decoders or anything, I can do that at my end.

thanks again!

Hmmm... No matter how many channels I set as active, I only get a maximum of 67.1 Msamples, which is only 336ms at 200MHz... In addition, if I try to set any triggers (hard to insert the plug exactly when I start the capture), pulseview freezes up completely. 🙁 I don't think the hantek driver for pv is particularly well written...

Edit: yeah, it all comes screaming back to me now, I never could get this to work properly years ago. And the Hantek software is so incredibly horrible too. I'll give it another shot tomorrow, but it's starting to dawn on me that I might be in the market for another LA...

Eivind wrote on 2024-05-20, 02:07:

Edit: yeah, it all comes screaming back to me now, I never could get this to work properly years ago. And the Hantek software is so incredibly horrible too. I'll give it another shot tomorrow, but it's starting to dawn on me that I might be in the market for another LA...

Ah OK. Maybe try reducing the capture frequency? We might be able to get away with like 60-80MHz...

Don't worry too much about it though, there are a few more differences between my code and tinyusb that I need to iron out

EDIT : I just checked the hantek site, it only has a 64M sample memory and only has a USB 2.0 connection. This is only going to be be marginally better than the pi pico. Sorry for making you dig it out but I don't think this LA is going to cut it 🙁

rasteri wrote on 2024-05-20, 09:05:

Ah OK. Maybe try reducing the capture frequency? We might be able to get away with like 60-80MHz...

Don't worry too much about it though, there are a few more differences between my code and tinyusb that I need to iron out

Keeping my fingers crossed then! 😀 Again, happy to send you more logs if you want to do a more verbose dump of data during the enumeration!

rasteri wrote on 2024-05-20, 09:05:

EDIT : I just checked the hantek site, it only has a 64M sample memory and only has a USB 2.0 connection. This is only going to be be marginally better than the pi pico. Sorry for making you dig it out but I don't think this LA is going to cut it 🙁

Yeeeah, looks that way. I mean, in theory it should be able to stream 100 Ms/s over a 480Mbit USB 2.0 connection, but I can't find any way of enabling streaming mode. And, as I mentioned yesterday, the triggering situation is messed up.
Not to derail this thread further, but do you have any suggestions for a reasonably priced LA? It might come in handy not just for this, but for my various other projects dealing with the ISA bus. Eyeing one of the DSLogic units, they seem to work well from what I'm reading.

Eivind wrote on 2024-05-20, 09:40:

Not to derail this thread further, but do you have any suggestions for a reasonably priced LA? It might come in handy not just for this, but for my various other projects dealing with the ISA bus. Eyeing one of the DSLogic units, they seem to work well from what I'm reading.

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