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 with OMAP35x OTG port

Other Parts Discussed in Thread: TPS65950, OMAP3503, TPS65073, TUSB1210

Hi All,

I am using OMAP3503 with TPS65073 PMIC (which does not have built in USB PHY like TPS65950). So, external USB PHY is required for OMAP OTG port. In my current design, I am using USB3322 from SMSC but I am facing issue with USB boot here. I am planning to use TI's TUSB1210 PHY with OTG port of OMAP35x. Now, I need some clarifications here

  1. Is there any power sequencing required for TUSB1210? As per datasheet, VBAT is shown to be powered first and then VDDIO but no timing information or delay is specified (Refer to Page 16). Also it is mentioned that PHY logic is reset if any of power supplies is not present (Refer to Page 13). In my current design, 3.3V (for VBAT) is enabled by GPIO from OMAP which is asserted only after 1.8V (for VDDIO) is powered. Can this create any issue with TUSB1210 and USB booting? I am more concerened about USB booting as I am replacing SMSC PHY with one from TI to resolve this issue only.
  2. In my current design, a single 12MHz oscillator is used for OMAP as well as SMSC PHY but TUSB1210 supports only 19.2/26 MHz reference clocks. TUSB1210 supports both Clock In and Clock Out modes. Now I dont want to add any addtional oscillator and am planning to use Clock In mode where 60MHz ULPI clock will be given by OMAP to PHY. But again I am not sure whether this configuration will work for USB booting or not. As I said before, USB booting is the only reason for me here to use USB1210 and holds highest priority here. So, if clock In mode is an issue for USB booting, I am always ready to add additional 26MHz clock source and use clock out mode. Can anyone advise me here?

Till now I have not come across any reference  board design where a USB PHY other than TPS65950 is used with OMAP OTG port. Has anyone out there tried any other PHY for OMAP OTG port successfully without any issue like USB booting (especially TUSB1210)?

Vini

  • Vini,

    OMAP3EVM uses ISP1507 PHY on OTG port instead of using PMIC PHY. You can refer OMAP3EVM schematics for your design.

    REgards,
    Ajay

  • Thanks Ajay,

     

    I forgot this completely. I had seen this long back and was under the impression that TPS65950 USB PHY is used and ISP1507 is given as an option but actually its other way.

    Anyway, can anyone clarify my TUSB1210 doubts?

     

    Regards,

    Vini

  • I will need to forward your question related to TUSB1210 power supply sequencing to someone else since I do not know the answer to this question.

     

    The ISP1507 and TUSB1210 transceivers connect to the USB controller via the USB specified UTMI+ Low Pin Interface (ULPI) which defines the electrical and register interface between the two components.  So the two transceivers should have equivalent operational modes.  However, you need to configure the TUSB1210 as the ULPI clock source to the USB controller since the ROM code that performs USB boot is not configuring the USB controller to source the 60MHz ULPI clock.

     

    I am not aware of any reference designs that use the TUSB1210 on the OTG port.  However, I will review your schematic and provide my comments if you attach the schematic of TUSB1210 connections to the OMAP3503 and USB connector.

     

     

    Regards,

    Paul

  • Hi Paul,

    Thanks for the clarification. I shall update the schematic later today for your review.

    Any update on power sequencing requirements for TUSB1210?

    Regards,

    Vini

  • Q1: Is there any power sequencing required for TUSB1210?... In my current design, 3.3V (for VBAT) is enabled by GPIO from OMAP which is asserted only after 1.8V (for VDDIO) is powered. Can this create any issue with TUSB1210 and USB booting?

    A1: Recommended operation is for VBAT to be present before VDDIO. Applying VDDIO before VBAT to TUSB1210 is not recommended as there is a diode from VDDIO to VBAT which will be forward biased when VDDIO is present but VBAT is not present. Consequently VBAT node will be charged to a diode drop below VDDIO, and may cause some internal leakage in TUSB1210. However it is unlikely this leakage will be significant, and since it is transitory only, it should be acceptable. I will check this in the lab however to be sure.

    This leads me to ask 2 questions:

    TIQ1: What is the state of the 3.3V (for VBAT) node when disabled? If there is a short to ground inside the 3V3 supply device then significant current could flow from VDDIO to ground when VDDIO is present anf the 3V3 is disabled. If this node is high impedance or there is a series switch between the 3V3 and TUSB1210 VBAT then there is no issue.

    TIQ2: Is there other external circuitry hanging off the 3V3 supply? Can such circuitry tolerate VBAT rising to a diode drop below VDDIO during the power-on transition?  

    Q2: In my current design, a single 12MHz oscillator is used for OMAP as well as SMSC PHY but TUSB1210 supports only 19.2/26 MHz reference clocks. TUSB1210 supports both Clock In and Clock Out modes. Now I dont want to add any addtional oscillator and am planning to use Clock In mode where 60MHz ULPI clock will be given by OMAP to PHY. But again I am not sure whether this configuration will work for USB booting or not. As I said before, USB booting is the only reason for me here to use USB1210 and holds highest priority here. So, if clock In mode is an issue for USB booting, I am always ready to add additional 26MHz clock source and use clock out mode. Can anyone advise me here?

    A2: TUSB1210 supports both Clock In and Clock Out modes, true. However OMAP OTG port only supports "Clock Out" mode, i.e., it expects 60MHz clock to come from the PHY (TUSB1210). Therefore a 19.2 or 26 MHz 3.0~3.6V square-wave reference clock must be provided to REFCLK pin of TUSB1210 in order to interface it correctly with OMAP OTG port.

    Best regards,

    Peter

  • Vini,

    In relation to A1 (in post above) I confirm that applying VDDIO 1.8V while VBAT is not present (VBAT pin high impedance) does not cause significant leakage current in TUSB1210. VBAT as expected rises to just below VDDIO (1.67V), and current on VDDIO supply increases only marginally (by 9uA). Of course answers to TIQ1, and TIQ2 (in post above) should also be considered before concluding that this is acceptable for your particular design.

    Best regards,

    Peter

  • Hi Peaves,

     

    In response to your post, I have a follow up question:

     

    Now, we understand that the power on sequencing is not an issue for TUSB1210 working. But still one thing that needs to be clarified is whether this power on sequencing for TUSB1210 (VBAT applied after VDDIO) can have some impact on OMAP USB booting. As per my understanding, 60MHz clock is provided by TUSB1210  to OMAP OTG port and this clock will be given by PHY only after VBAT is stabilized but what I am not sure here is whether OMAP BOOT ROM code will wait for this clock to start for USB booting or not.

     

    Is there a timeout as per OMAP BOOT ROM code in which the 60MHz clock from PHY should become stable for USB booting? In that case there may be some limitation on the delay allowed from the moment I/O rail of OMAP (VDDS=1.8V) is powered to 60MHz clock stabilization from PHY for successful USB booting. Can you please confirm whether we need to take care for any such delay?

     

    -J

  • I was told USB boot was verified on the OMAP3 EVM using the ISP1507 and the optional TPS65950.  

    As you mentioned, the biggest concern is your power sequencing may cause the TUSB1210 to delay its startup because the ULPI specification requires the Phy to reset properly after the power supplies are valid.  In your application the TUSB1210 VBAT power supply will be delayed which will delay the startup.

    I do not know how much startup time margin is provided in the ROM code.  I will ask if any one knows if this parameter was characterized during ROM code development.  However, it may take a few days before we get an answer.

     

    Regards,

    Paul