XUD Issue attaching when connected at power up

[bearcat]

As a follow up, I am not completely sure of the root cause. I believe it is a timing issue. I did dive into looking at the AttachHS routine, but did not conclude anything, without more information. The clocking and setup of the ports is very complicated. Some secret processor register.

It is missing the final squelch over the ULPI bus as the last step before HS USB operation, and therefore hangs forvever. If I short circuit that last input, the device attaches and operates ok. That's what led me to believe it missed it as the cause.

The design matches the reference in the USB section. Once connected, the USB runs error free for hours. Using an earlier code base, it worked on that hardware. I have seen this problem before on other code bases and boards (and earlier XUD's). The attachHS sequence is relatively slow??? I never concluded if XUD is looking for just 3 J/K pairs then a squelch, or something else. My code is 6 threads @ 500MHz on that tile. Tried 500Mhz vs 500.5Mhz, didn't do anything. I tried delaying start for all the USB threads for some time, but that didn't work either. Tried fast mode on XUD. During testing, I did see it attach 1 out of about 30 or so. Which leads me to believe it's close.

My best guess, is my code base is running the processor at more load at startup than the reference and slowing XUD during some critical timing loop. Extending reset doesn't seem to make much sense to me. I don't know what the UIFM_RX_DATA_PORT <: 0 does either. Happily it worked...

[Ross]

Extending reset doesn't seem to make much sense to me. I don't know what the UIFM_RX_DATA_PORT <: 0 does either. Happily it worked...

This output its the important bit rather than the reset timing (I made the delay up off the top of my head so it could be different from the original lib...). The output ensures that the ULPI data lines are hard 0 such that the phy doesn't clock in any erroneous data before the XMOS ULPI interface is up and running.

This output was already in previous library versions, so it was a regression.

Also, a different fix is simply to declare the following in the project:

in port p_usb_stp = XS1_PORT_1E.

By simply enabling the port the pull-down on the I/O is disabled - so it doesn't fight against the pull-up on the STP line on the phy.

I prefer this fix, please give it a go!

[Ross]

Also, what SMSC part are you using please?

[bearcat]

Sorry Guys, been on a business trip this week, so haven't been able to continue this.

Ross, I will try the input port. I will also vary the time delay. I want to nail this down as well.

I am using the SMC 3318, see below:

USB3318.JPG

[bearcat]

Ross, just declaring the input also works. Looks like you have a handle on the problem here.

I will leave it at this method.

Thanks again.