• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 4 answers
  • Subscribers 31 subscribers
  • Views 2810 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: TUSB12 controller layer

sara samdi
Prodigy 120 points
Part Number: TUSB1210

Hi Experts,

in my costume board, that is a FPGA-based board, I want to have usb2.0 with OTG support.

I choose TUSB1210 as Transceiver and now I want to write a usb driver in FPGA,

but I am confusing about OTG implementation.

in datasheet have been said TUSB1210 supports SRP and HNP,

do this means that : "I should just implement ULPI protocol in FPGA , and is not need to consider HNP and SRP protocols"?

and so implement of ULPI protocol is the whole of work that I should to do?

please guide me to do this.

Thanks.

  • 0
    TI__Expert 7395 points
    Hello Sara,
    I am reviewing your question and will come back with an answer as soon as possible.
    Please note that response times may be longer due to the holidays.
    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points
    Dear Jorge,
    OK I will wait for your response,
    Thanks a lot.
  • 0 in reply to sara samdi
    TI__Expert 7395 points
    Hello Sara,

    The ULPI specification fully supports "Session Request Protocol". So, by implementing the ULPI protocol on your link, your device should be able to determine the beginning or the end of a session by monitoring the ChrgVbus and DischrgVbus bits in the OTG_CTRL register.

    Similarly, your link/system would need to implement the "On-The-Go Supplement to the USB 2.0 Specification (Rev. 1.3)" to fully support HNP as defined by that spec.

    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    Hello Jorge,

    Thanks a lot for your response,

    as your response, I should implement HNP protocol in my link core,

    but my ambiguity is this sentence in TUSB1210 datasheet:

    "complete USB OTG Physical Front-End That Supports Host Negotiation Protocol(HNP) and Session Request Protocol(SRP)"

    that caused I think this isn't need to implement HNP and SRP.
    if it's a wrong understanding, please say me what is this sentence mean?

    another question, how link can understand that should behave as host or should go to OTG mode? it is not clear in OTG_CTRL register!
     
     
    thanks a lot.
    sara.

  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points
    Dear Jorge ,

    I'm waiting your response please,
    Thanks.
  • 0 in reply to sara samdi
    TI__Expert 7395 points
    Hello Diane,

    My apologies for the delay in my response. "Physical Front End" refers to the analog circuits, such as comparators, drivers, pullup, etc., to support the sequence of steps required to implement HNP and SRP.

    As mentioned before, your link/system would need to implement the "On-The-Go Supplement to the USB 2.0 Specification (Rev. 1.3)" to fully support HNP as defined by that spec. I would recommend you to check specifically section 6.3 which clearly details the steps that would need to be performed by your link/software layer.

    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    Hi Dear Jorge,

    Thanks for your clear response,

    I have another question about Data Transferring Direction bw  PHY and Link:

    As I checked “ULPI Specifications”, “dir” pin with help “nxt” and “stp” pins determine that when link is transmitting data to phy and when it’s receiving. And assert/de-assert of dir is in PHY disposal.

    On the other hand, TX CMD is a command from the link to PHY that determines Transaction type such as IN/OUT. So it seems when link wants to transmit data, it sends an “OUT TX CMD” and when it wants to receive data, it send an “IN TX CMD”.

    Now my question is that: witch of “PHY” or “link” determines the Data Transferring Direction? And what is difference of transmit/receive from IN/OUT?

    Thanks a lot.

    Sara

  • 0 in reply to sara samdi
    TI__Expert 7395 points
    Sara,

    The ULPI spec does a pretty good job describing how this works:

    "DIR - Direction. Controls the direction of the data bus. When the PHY has data to transfer to the Link, it drives dir high to take ownership of the bus. When the PHY has no data to transfer it drives dir low and monitors the bus for Link activity. The PHY pulls dir high whenever the interface cannot accept data from the Link. For example, when the interna PHY PLL is not stable."

    So the Link monitors DIR, when it is low it is allowed to send a command/data to the PHY; then the PHY will set DIR high while it processes the data/command and after completion it will release DIR (back to low) so the PHY can send a new command/data to the link.

    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    Dear Jorge,

    Thanks a lot,

    but I checked that before,

    look, assume that dir is low and so link has ownership of the bus.

    Now, first assume link sends an "IN TX CMD".

    that means link want to have a host-to-device transaction.

    secondly, assume link sends an "OUT TX CMD".

    that means link want to have a device-to-host transaction.

    what is the difference between these two CMDs  from the point of view  data transferring direction between link and phy?

    Thanks.

  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points
    is there any idea please?
  • 0 in reply to sara samdi
    TI__Expert 7395 points
    Hello Sara,

    Can you please elaborate what you mean with "IN TX CMD" and "OUT TX CMD"? Tables 6 and 7 on the ULPI specification rev. 1.1 define the different format options for the Transmit Command Byte (TX CMD) and Receive Command Byte (RX CMD); although I couldn't find any reference to the above mentioned commands.

    In any case, section 3.8 has detailed descriptions and diagrams showing the dataflow for each command.

    As mentioned before, the device is fully compliant with the ULPI specification revision 1.1; for details on the device operation, please refer to the spec.

    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    Hello Jorge,
    thanks for your response,
    as mentioned in Tables such as  13,14 in same spec., before Data should send a PID. look:

     

    so, I searched a bout PID in USB packet  and I understand that PID determines Data type according to following table:

     

     


    according to this table, TX PID IN is host-to-device transaction and   TX PID OUT is device-to-host transaction.
    so, I repeat my question :

    assume that dir is low and so link has ownership of the bus.
    Now, first assume link sends an "IN TX CMD".
    that means link wants to have a host-to-device transaction.
    secondly, assume link sends an "OUT TX CMD".
    that means link want to have a device-to-host transaction.
    what is the difference between these two CMDs  from the point of view  data transferring direction between link and phy?

    Thanks a lot,

    Sara.

  • 0 in reply to sara samdi
    TI__Expert 7395 points
    Sara,

    TX PID OUT and TX PID IN are nomenclatures used by that particular document you are referring to, which is neither the ULPI nor the USB specification.

    If you check the USB 2.0 specification at section 8.3.1, you will find out that PID 0001b is the identifier for a token OUT packet, and PID 1001b is the identifier for a token IN packet.

    A token OUT packet informs the USB device that the USB host wants to send data. A token IN packet informs the USB device that the USB host wants to read data. In both cases the Link has to wait for DIR to be low (ULPI bus free) before sending this commands to the phy, which, in turn, will send the corresponding USB packet afterwards.

    I hope this helps to clarify your question.

    Regards,
    Jorge
  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    dear Jorge,

    In my mind, "A token IN packet informs the USB device that the USB host wants to read data" is equal Receive process. 

    is it incorrect?

    look,

    here is my system:

    and I want run it just in High Speed mode.

    I think

    when I want send data from PC to Link, so PHY sends an RXCMD to LINK and then send data to Link in form of byte-byte (Receive).

    when I want send data from Link to PC, so Link should send a TXCMD with MDATA PID Token and then should  send data to PHY in form of byte-byte (Transmit).

    now please say me why do I need to send  TXCMD with IN PID Token?

    Excuse me for a lot of questions.

    Thanks a lot.

  • 0 in reply to Jorge Llamas (SWAT)
    Prodigy 120 points

    dear Jorge,

    In my mind, "A token IN packet informs the USB device that the USB host wants to read data" that you said,  is equal "Receive process". 

    is it incorrect?

    look,

    here is my system:

    and I want run it just in High Speed mode and just in synchronous mode.

    I think

    when I want send data from PC to Link, so PHY sends an RXCMD to LINK and then send data to Link in form of byte-byte (Receive).

    when I want send data from Link to PC, so Link should send a TXCMD with MDATA PID Token and then should  send data to PHY in form of byte-byte (Transmit).

    now please say me why do I need to send  TXCMD with IN PID Token?

    Excuse me for a lot of questions.

    Thanks a lot.