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.

TPS3836: CT time delay

Part Number: TPS3836

Team,

 

My customer has the following problem: 

 

Problem:

Pin 4 /Reset is being asserted approximately in a 580us to 680us window after Pin 3 /MR transitions high , instead of either 10ms (with CT tied low) or 200ms (with CT tied high).  We are trying to understand how could this occur if we met the requirements of the data sheet with tying CT low, or tying CT high.   Per your data sheet the following is stated about the time delay:

 

 

 

So we are trying to understand the aggressor that could cause the part to act uncharacteristically as defined per your data sheet.  Regardless of whether we tie CT high or low we get the same window of Time Delay.

 

Our Test Conditions using TPS3836K33DBVT:

Note: The below pin configuration is in place upon the application of power.  Our 3.3V  rail (tied to VDD) is up before the DONE line assertion to Pin3 /MR.  So essentially the threshold condition has been met with the 3.3V application, then just waiting on the DONE line assertion to /MR.

 

Pin 1 (CT):  Tied either directly to signal return (i.e. 3.3V return; same return as tied pin 2); or tied directly to 3.3V (same voltage rail as tied to pin 5 VDD).  Our normal setup is to tie to VDD.

Pin 2 (GND):  Tied directly to signal return (i.e. 3.3V return).

Pin 3 (/MR): Tied to Configuration DONE pin of a FGPA.  When Configuration  of FPGA is complete the DONE line transitions high.

Pin 4 (/RESET):  Tied to reset of our processor

Pin 5 (VDD):  Tied to 3.3V rail.

 

 

Thanks in advance for your support.

Regards,

Aaron

  • Aaron,

    From the datasheet, you are correct that the delay should be closer to 10ms or 200ms. Do you have scope captures of the /MR signal and /RESET signal? Is it possible that the internal pull-up resistor at /MR is pulling the signal line up before the DONE signal transitions causing what appears to be a shorter than expected delay? Please provide a scope capture so we can see more detail of the signals in your application.

    -Michael