• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 567 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TUSB1210 - START ADDRESS COMMAND FROM HOST NOT RECEIVED AFTER DEVICE PHY INITIALIZATION

ARM arm
Expert 2630 points
Hi,
We are interfacing an FPGA between Motherboard and Pen Drive. We want to process the USB SCSI payload being transferred between motherboard and a pendrive / mass storage device.

Now the problem statement is when we want to initialize the device PHY [PHY interfacing with the motherboard] as per the following document :-

http://videosolutions.ltd.uk/tech-articles/ULPI%20interface.html

We are able to initialize the PHY with chirping etc. as per Figure 4 in the link doc. Now we start getting SOF packets and One Get Device Descriptor request from the HOST which we reply appropriately [within two SOF packets once]. Now there after we see SOF packets trains which get stopped after few seconds.

We do not  find SETAADDRESS command as mentioned in a long device enumeration table in the link and we are confused regarding a second device reset mentioned in the document.

Now can you please tell me :-

Is SOF the first packet that is observed after device initialization [i.e. after chirp, squelch, not squelch]? Will the SOF packets continue as long as USB link is maintained? We receive SOF after 50oddms of initialization in windows 8 and 12 ms odd in windows 7. Is it normal behaviour? Shouldn't the device phy be reset observing no activity for 50 /12 ms after initialization?

When does this second device reset comes from the HOST or does it ever come? If so then how do we detect it and will it again cause chirping etc?  Again will the SETADDRESS command will follow the second device reset?

And if this second device reset does not come at all, then why we do not see SETADDRESS command at all? Are we missing something?
We are using Windows 7 / 8 for pen drive enumeration.
Please Please help...
  • 0
    Intellectual 565 points

    I think much endpoint functionality is not available until you have applied a "reset"

    Quoting from USB_20.pdf spec:

    5.3.1.1 Endpoint Zero Requirements
    ........................The endpoints with endpoint number zero are always accessible once a device is attached, powered, and has received a bus reset...........

    So there is a chance you might not get a response until the host has reset the device. In the example in the (my) link you gave I recall getting just a single transaction. I confess that the article may be not be complete as indicated by the first transaction before reset is a "2D 01 E8" which is a setup for endpoint "01".  It could be that some other device on the bus actually replied rather than the one intended.

    I would expect to receive SOFs straight away after initialisation. The question though is when does your initialisation finishes? Can you confirm there is a gap of 50ms after the last J/K Chirp and the first SOF?  That sounds very wrong.  The host side PHY (acting as client to MB) should enter HS mode while receiving the J/K Chirp.

    I would expect to see a few 100ms of SOFs before the first/next reset. Reset is simply no activity on the bus for a nominal 3ms, ie no SOFs, with a continuous linestate of "00" indicating Squelch.

    For me, SOFs/bus activity are the key to discovering when the host is applying reset. After reset, much of the chirping is as per the initialisation after first connection.

  • 0 in reply to Mike Perkins
    Expert 2630 points
    Dear Mike,

    Would like to continue this thread a little more since the topic is still relevant with my problem.

    My findings :-

    After first PHY initialization and sequence of 3 JK chirps, we see a series of J-K for a period of say 50 odd ms in squelch mode i.e. these chirps are of height - 400 to 500mV as seen on the scope. There after we find the first SOF starting from the host and and then we One Get Device Descriptor request from the HOST which we reply appropriately [within two SOF packets once] as mentioned in your document [although end point address is 00 and not 01 as mentioned in you link, so that is ok.].

    Thereafter, we are getting SOF for say 100 odd ms and then they stop to which we again begin the process of re-initialization i.e. second reset, chirpings etc. to which the host responds. But then again once SOF starts we again get GET Device Descriptor request rather than SET ADDRESS request as mentioned in the long table in your link as well as KANNAN's document.

    Why is it so is not clear to me Mike, would seek your help in it.

    Many Regards.
  • 0 in reply to ARM arm
    Intellectual 565 points

    50+ms of JK chirp seems rather excessive. The device should see a minimum of 3 Js and 3Ks before entering HS receive state. They should only last until the end of the reset time, which I thought was 10ms?

    To quote the ULPI document "The peripheral is now in Hi-Speed mode and sees !squelch (01b) on LineState. When the peripheral sees squelch (10b) on LineState, it knows the host has completed chirp and waits for Hi-Speed USB traffic to begin."

    My understanding was the device ought not respond to traffic before the (second) reset, but that the PC sends some packets because some old devices require it.

    I would have thought after reset, any setup address would have been forgotten?  What is the address in the SETUP/IN/OUT packets? Are they "0" or some other number?