Stack with usb hub and keyboard doesn't enumerate completeley

[Makurisan]

Set Up

• PC OS Windows 10
• Board* Samg55
• Firmware 4 Port Hub with keyboard attached

Describe The Bug If I attach the Hub and the keyboard the enumeration stops at GetDeviceDescriptor To Reproduce

tusb_init(); // initialize tinyusb stack

while (true) {
	tuh_task();
}

Steps to reproduce the behavior:

1. plug in the hub
2. plug in the keyboard
3. See error stop on GetPortStatus

Screenshots

If applicable, add screenshots, bus capture to help explain your problem.

Log

812.txt

[Makurisan]

I dont know why but the GetPortStatus is not completed:

00> HUB Get Port Status: addr = 1 port = 5 00> Control Setup: A3 00 00 00 05 00 04 00

Last ouput in the log.

[hathach]

Please fill out all the detail in bug template in the first post. It is mandatory. This issue will then be reopened

[Makurisan]

moved to fist post

[hathach]

Thanks for updating the issue following the template. The SamG55 host driver is unfortunately not supported yet. I am surprised that you could get this far. Are you implementing the host driver locally. Looking at the log, look like the stack could recognize the hub and usb device attach event and able to communicate up to getting 8 bytes of device descriptor. The code that run up to the log is at https://github.com/hathach/tinyusb/blob/master/src/host/usbh.c#L745.

1. Did you implement the hcd_frame_number() to return the frame number ? it is currently used to perform reset delay (not ideally, but it is WIP).
2. Also the screenshot is not really helpful, it only stop at the hub enumeration, and not the device enumeration afterwards where there is 8 byte of device descriptor is requested. Could you re-upload the screenshot including that part.
3. Have you tried to test with another hub just to check. Host stack is still WIP. 4 The transfer bytes is way off 4294967295, but it looks like a minor mis-reprenstation of integer size. Please fix that to have a cleaner log

[Makurisan]

1. No I didnt implement or changed on hcd_frame_number.
2. Yes, I do it if I saved my tests.
3. Yes, I did test it with different hubs but always the same result.
4. transfer bytes. Yes, I checked it. It is not a problem.

I come nearer to the problem. In the file usbh.c at line 739 you initiate the reset after the 8 byte descriptor and normally the enumeration comes back with SetAddress after the second reset. This does not happen. What happens is that the stack blocks. I see on the code that you have had problem with the Reset and therefore you make this tuh_task inside the completion. This is in my opinion not good and should be cleaned. I see on your comment that you had this also in mind. I have implemented on the samd51 a complete host with multi hub support and there it works fine with port reset and port get status. I don't know what is here the problem. Do you have any idea?

[Makurisan]

As I mentioned after the call of port Reset from usbh.c at line 739 and following lines.

[hathach]

@Makurisan try to implement the hcd_uframe_number(), it is probably the issue, the reset must stay long enough. Your problem wihtout implement it is

1. osal_task_delay() (based on frame number): is not last long enough
2. tuh_task() is called, but the port change status is not occurred yet. This may mess up with the follow up call.

hcd_uframe_number() is easy to implement, just return the current micro-frame number. Since SAMG is full-host, you need to multiple norma frame number it with 8. the tuh_task() call is a bit hacky, I am fully aware, just doesn't have the time to fix it. Will do it next time when I work with host.

[Makurisan]

Hm, I think it is long enough. In the usb 1.1 spec it is said that a port reset on a hub is nominally from 10ms to 20ms. If I do the following

and

then the stack enumerates completely. I know that you makes this GetPortStatus and after that you check the Reset change...

[Makurisan]

Which board you use normally to check the OHCI hub code?

[hathach]

@Makurisan oh, I just realize, samg also use OHCI. I normally test with LPC1769 for OHCI, but it has been quite some time. Currently I mostly use lpc18xx EHCI when working on host stack. I really want to improve the host stack, but couldn't find the time to so. I will for sure pull out the samg to test with OHCI next time I work on it.

[Makurisan]

Yes, it is really interesting that the samg55 use OHCI. I tested it because I want low speed. I don't know if you know but low speed has some specialties and not all MCUs USB devices are fully compatible nowadays and specifically as the act as an root hub.

[Makurisan]

Now I came up width the following solution:

[hathach]

I am glad you figure a way to get it work. Since I will revise the code anyway later on, I pay more attention to this case.