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.

TUSB2036: EEPROM and hub reset timing

Part Number: TUSB2036

I created a MCU-based circuit and have used it successfully to initialized the M96C46 EEPROM via a card edge connector.  Referring to the attached schematic to do this, my MCU holds the hub in reset via J6E, and drives J6K (chip select), as well as the clock and data signals.  Then I disconnected this MCU circuit and connected the hub directly to a USB port on a Windows PC.

 Since the hub datasheet suggested 100µsec to 1ms reset time, I’ve measured R2/C5  hub reset voltage levels to be < 0.8 Vdc (Vil max) asserted for 200µsec, and reset reaches Vih min (~1.8V) at about 800µsec from a “brick wall” rise time for the 3.3Vdc rail.  Note that the 3.3V rail is created by a LDO with Vbus for Vin. and the C4 & C11 bypass caps are not installed contrary to the schematic.  However, with this reset timing, the hub doesn’t communicate with the EEPROM, but does operate properly other than reporting the incorrect VID = 0x0000 and PID = 0x0000 to Windows Device Manager.  Presumably the hub is configured as “ganged” overcurrent protection (at EEPROM address 0x0000) since this is what was reported for the VID/PID.  EEPROM datasheet for reference https://www.st.com/resource/en/datasheet/m93c46-w.pdf

 I changed R2 from 10K to 100K, and observed EEPROM communications about 6.7ms after the "brick wall" 3.3V power supply comes up.  Device Manager reports the hub VID/PID that I had previously written into the EEPROM with my MCU circuit. 

But I’m also concerned about having too long of a reset from an EEPROM communications perspective as well (in addition to too short).  I also tried R2 = 100K and C5 = 1µF which resulted in the correct VID/PID.  However, I’ve twice observed the correct initialized VID, but 0x0000 for the PID upon virgin power-up on two different units.  Both units seemed to report the correct VID / PID on subsequent disconnect / reconnect events.

 So there appears to be a critical timing window for EEPROM communication, and tradeoffs between hub USB response time and EEPROM communication;  I’m concerned about reliability.

 Schematic Can you offer any insight and guidance?

  • Wayne:

    EEPROM read should be start after power on reset. TUSB2036 performs a one-time access read operation from the EEPROM if the EXTMEM pin is pulled low and the chip select(s) of the EEPROM is connected to the system power-on reset, btu EEPROM read its self took some time.

     One more critical is CLK should be start at the end of reset, did you look at crystal signal and the relation between reset?

    Best

    Brian

  • I couldn't find a timing specification for the crystal relative to the reset within the datasheet other than "Clock signal has to be active during the last 60 μs of the reset window".  But what voltage level at XTAL1 is "active", since I'm using a passive crystal with a start-up envelope?  Does "clock active" mean that XTAL1 has VIL(TTL) <= 0.8V and VIH(TTL) of 2V min, during which time RESET is <= VIL(TTL) min? 

  • Wayne:

          the only timing for clock is  "Clock signal has to be active during the last 60 μs of the reset window".

          Clock active means here that crystal clock reaches Vih (2v) and stable . which is 60us before RESET is done.

          Did you look at power supply and clock waveform yet?

    Regards

    Brian

           

  • Brian:

    You stated that  "Clock active means here that crystal clock reaches Vih (2v) and stable which is 60us before RESET is done."  However, my crystal takes about  6-7ms to reach Vih (2V) and stable (see link below).  But a TI document SLLA314 March 2011 stated "Texas Instruments recommends a minimum of 100 µs to a maximum of 1 ms of reset timing. If the hub is held in reset for a longer period of time, it can fail to respond promptly to USB host signaling and not complete enumeration. This is typically an issue with embedded system applications."  So apparently the hub switches-in it's D+ pull-up when the power supply comes up rather than after the reset pin is Vih (2V)?

    So the time it takes for my crystal to start up and stabilize is about 7x longer than the maximum suggested 1ms reset time.  

    When I changed R2 from 10K to 100K to increase my RC reset time, I observed EEPROM communications about 6.7ms after the "brick wall" / fast rise time 3.3V power supply comes up.

    3.3V to XTAL1 start-up: https://www.dropbox.com/scl/fi/uhemmocptg0l0zj1hnsdt/Vcc-to-XTAL1.bmp?rlkey=4b0gcw1bovyxe37b2fivmynfw&dl=0

    Thanks,

    Wayne

  • P.S.  The above 3.3V to XTAL1 start-up link above was with a 680 Ohm resistor instead of the recommended 1.5K XTAL2 series resistor which didn't give me a high enough amplitude with my crystal.  I'm now testing lower values to pull the low voltage closer to 0V.

  • Wayne:

           First issue we need to resolve is that crystal startup time is too long. TUSB2036 will not get reset correctly  without stable clock when RESET signal goes high.

          We may need to find crystals with fast startup time.

    Regars

    Brian

  • Brian:

    Here's the crystal specifications from the TUSB2036 datasheet: "Fox Electronics – part number HC49U-6.00MHz 30\50\0±70\20, which means ±30 ppm at 25°C and ±50 ppm from 0°C to 70°C. The characteristics for the crystal include a load capacitance (CL) of 20 pF, maximum shunt capacitance (Co) of 7 pF, and the maximum ESR of 50 Ω. In order to insure enough negative resistance, use C1 = C2 = 27 pF. The resistor Rd is used to trim the gain, and Rd = 1.5 kΩ is recommended."

    The Fox Electronics part number is no longer available.  The closest crystal I could find was ECS Inc: ECS-60-20-5PX-TR which met all of the above specifications, except that the equivalent ESR was 70 Ω instead of 50 Ω which was the lowest I could find compatible with the other specs.  I can't change the drive level and am using the recommended crystal capacitance.  So I'm looking for suggestions to shorten the crystal start-up.

    The below screen capture shows the reset voltage to crystal start-up.  I'm assuming that the hub does start driving the crystal until Reset Vih = 2V?

    Reset to XTAL1

  • Wayne:

         Let me discuss with our designer if ESR is critical for crystal startup time.

    Regards

    Brian

  • Brian:

    I know that the ESR does affect the start-up time.  Please recall that I couldn't find an ESR lower than 70 Ohms while still meeting the other electrical specifications.  The crystal I chose was a ECS Inc: ECS-60-20-5PX-TR with a HC-49/US footprint.

    Thanks,

    Wayne

  •  One customer used ABC2-6.000MHZ-4-T from Abracon. and startup time is around 2ms, it looks much better than 5ms you saw.

    Regards

    Brian

  • Brian: 

    While this has 60 Ohms ESR (better than the 70 Ohms of my ECS crystal), it's still higher than the TI spec'd 50 Ohms.  The problem with this part is that it has a 4-SMT footprint and my PCB has already been fabricated with a HC49/US footprint.

    Can you confirm that the hub does start driving the crystal until Reset Vih = 2V?  Or does the hub start driving the crystal as soon as Vcc=3.3V is applied?  When does the hub switch-in the D+ pull-up, at which time USB discovers the hub is connected?

  • Wayne:

          Design has not respond the question about how hub driving the crystal today. I will find it out by Monday.

    Best

    Brian

  • Brian:

    It's been a week from last "Monday" since your last correspondence.  Think that means that the design group isn't going to respond?

    Thanks,
    Wayne

  • Wayne:

       Sorry for the delay, since this device was designed 20 years ago,it took some time for design to find the database.

     This is  the block diagram for crystal oscillator. The GZ port controls the oscillator's functionality. GZ can disables the oscillator and applies high impedance to the output. Design is still checking if XI/XO is off during reset.

    Regadrs

    Brian