TUSB4041I: TUSB4041 behavior when GRSTz is deasserted at the same time as Power-ON

Hi,

I also would like you to confirm whether following two cases are available or not.


In general, user will follow above case 1.
However, according to following description of datasheet "8.3.7 Power-Up and Reset", it seems above case 2 is available as well.

* Description of "8.3.7 Power-Up and Reset"
The device requires a minimum reset duration of 3 ms. This reset duration is defined as the time when the power supplies are in the recommended operating range to the deassertion of the GRSTz pin.

Could you please confirm above as well ?

Best Regards,

Hi,

Could you please give your feedback ?

Best Regards,

what is issue for your customer?

if VDD11 is up beforeVDD33 10us, there is no 3ms requirement for GRST low.

if VDD11 is up at same time with VDD33 or after VDD33, then GRST needs to keep low at least 3ms after both VDD/VDD33 is stable.

Best

Brian

Hello Brian-san,

>what is issue for your customer?
I do not hear exact issue on customer side, i will check it.

>if VDD11 is up at same time with VDD33 or after VDD33, then GRST needs to keep low at least 3ms after both VDD/VDD33 is stable.
Let me confirm about below.

* What I would like to confirm is required state of "GRSTz" during powering up of VDD33/VDD11 above case.
Actually, you show figure 1 about powering up. However on the other hand, there is no description about state of "GRSTz" during powering up in following sentence of section "8.3.7".
Is it allowable to stay "High"(deassertion) state for "GRSTz" before VDD11 is stable as shown above "case 2" which I posted ?

* Description of "8.3.7 Power-Up and Reset"
The device requires a minimum reset duration of 3 ms. This reset duration is defined as the time when the power supplies are in the recommended operating range to the deassertion of the GRSTz pin.

Best Regards,

Ryuuichi machida said:

This reset duration is defined as the time when the power supplies are in the recommended operating range to the deassertion of the GRSTz pin.

no, Td2 is GRSTz in low state  for 3ms after power supplies are in operating range.

Best

Brian

Hi Brian-san,

Let me do double check.
>Is it allowable to stay "High"(deassertion) state for "GRSTz" before VDD11 is stable as shown above "case 2" which I posted ?
Did you mean that answer of above is also "NO" ?

Best Regards,

GRSTz  can be  high or low before Td2, but Td2 has to be 3ms low after VDD11 and VDD33 are stable in operating range.

Regards

Brian

Hello Brian-san,

I have following question about internal behavior of "GRSTz".
Customer is asking what operation is performed when "GRSTz" is asserted.
Customer assume following operation is performed when "GRSTz" is performed. If you have any information which you can disclose, could you please comment about following assumption ?

* Initialization of internal state machine.
* Initialization of internal register.
* Calibration of internal USB PHY.
* Boot up internal firmware
* Latch to external configuration pins

Best Regards,

Hi Brian-san,

Thank you for your reply.
>>what is issue for your customer?
>I do not hear exact issue on customer side, i will check it.
I got information about above from customer.
Customer observed "USB host detect repetitive disconnect" behavior on their system.
Customer said this behavior was observed even though "disconnect" state should NOT occur.

If user did not operate correct GRSTz assertion when powering up (the case VDD33 will ramp up before VDD11), do you think that this behavior will occur ?

Best Regards,

It could be, can  customer take waveform for 3.3v/1.1v/GRSTz?

Best

Brian

Hi Brian-san,

Thank you.
 >customer take waveform for 3.3v/1.1v/GRSTz?
I got waveform 3.3V vs GRSTz. However customer said 1.1V also ramp up same timing as 3.3V.


>It could be, 
If possible, could you add comment/scenario about how this phenomenon may cause ?
Here is one of example hypothetical scenario.
"Due to improper GRSTz operation, initialization of internal state machine might not work correctly.
This condition might appear as observable behavior by the customer."

Best Regards,

Do you have cap on GRSTz  pin? Can you change it to 1uf?

Best

Brian

Hi Brian-san,

>Do you have cap on GRSTz pin? Can you change it to 1uf?
I'm sorry I did not share current customer's situation.
Customer now fixed their improper GRSTz problem by controling GPIO for GRSTz (Create "low"(assertion) signal) .
However, customer need to explain that their observed behavior (as I described previous thread ""USB host detect repetitive disconnect".) is related to improper GRSTz operation.
So, I asked previous following question.
---
If possible, could you add comment/scenario about how this phenomenon may cause ?
Here is one of example hypothetical scenario.
"Due to improper GRSTz operation, initialization of internal state machine might not work correctly.
This condition might appear as observable behavior by the customer."
---

Of course, we understand customer need to follow VDD33/VDD/GRSTz requirement, however I would appreciate your opinion on the above, even if it's just a guess.

Best Regards,