DP83867IR: Reset Pulse duration

Hi Machida,

Q1)

It's likely the device is stuck in reset state due to 15ns pulse.

If pulsing RESET_N properly after this 15ns pulse does not pull the device out of this state, then power-cycling the device is the only remaining option.

Q2)

Does customer expect the MCU will always drive RESET_N high during functional operation? If so, 2.2k PD is an acceptable workaround.

Alternatively, is it possible for MCU to configure GPIO pin as internal PU? I'm wondering if we can configure this pin to avoid the 15ns pulse while the GPIO is set as output.

Thank you,

Evan

Hi Evan,

>It's likely the device is stuck in reset state due to 15ns pulse.
Is the above a possible event from viewpoint of device design ?

>Alternatively, is it possible for MCU to configure GPIO pin as internal PU? I'm wondering if we can configure this pin to avoid the 15ns pulse while the GPIO is set as output.
Is there any concern what user implement external PD to "Reset_N" pin ?
I need to check detail. However, if the root cause of this issue is related to behavior of "change pin state" of MPU, even if they change internal pin state to PU, this issue will keep to happen.

Best Regards,
 

Hi Machida,

Ryuuichi machida said:

Is the above a possible event from viewpoint of device design ?

Yes, this event occurs from device's internal state machine.

Ryuuichi machida said:

Is there any concern what user implement external PD to "Reset_N" pin ?

This is only a concern if MCU is not able to maintain PU state on pin during functional operation. Otherwise, it is okay.

Ryuuichi machida said:

However, if the root cause of this issue is related to behavior of "change pin state" of MPU, even if they change internal pin state to PU, this issue will keep to happen.

Can the MCU be powered & GPIO pin state changed before PHY is powered?

Thank you,

Evan

Hi Evan-san,

Thank you for your reply.

- 1 -
>Can the MCU be powered & GPIO pin state changed before PHY is powered?
Customer said it is difficult.
Because, they control power sequence by using PMIC.
And also, they said this phenomenon is observed only "reboot" behavior.
This means they only reset CPU and do NOT perform power up and down sequence itself. Therefore, this action does not have no effect.

- 2 -
They said when they change setting timing of "GPIO" to output too fast than previous timing, they did not observe this issue as well.
Here is difference between timing which they observed issue and they did not observe issue.

* Case customer observed issue (This is same as second waveform which I posted previous thread.)



* Case customer did NOT observe issue.


The changed point is that customer performed "Reset" as soon as possible.
Though they still observe unexpected short pulse, however they did not observe issue after appling this change.
However, they can not judge whether this workaround is proper. Could you comment what you think about this change ?

Best Regards,

Hi Machida-san,

I will summarize current status, please correct any misunderstanding:

PHY enters "stuck" state when reset is pulsed low for 15ns. There are two possible workarounds customer has tested:

1) Adding PD on RESET_N line

2) Shortening the duration of RESET pulse to 8ns.

In case (1), this is an acceptable workaround if customer expects MCU will keep the line driven high during functional operation.

In case (2), the pulse at 8ns seems short enough to prevent the PHY from entering the RESET state machine and becoming stuck. While this is an acceptable workaround if customer does not observe the issue over many power-cycles, please note we have not characterized this behavior.

Thank you,

Evan

Hello Evan-san,

Thank you for your reply.

>1) Adding PD on RESET_N line
Yes.

>2) Shortening the duration of RESET pulse to 8ns.
No. What they changed is timing when they assert "Reset" for PHY.
For first case, they asserted "Reset" after approx 15ms they enabled GPIO[out].
However, for second case, they asserted "Reset" soon they enabled GPIO[out].

Duration difference of short pulse is not intentional change.

Best Regards,

Hi Machida-san,

Thank you for clarifying.

In this second case, it seems shortening the duration from GPIO glitch to RESET_N driven low allows the PHY to proceed with reset state machine without entering this stuck state. We have not characterized the behavior for this case, but it is acceptable if this timing is consistently observed and there are no functional issues.

Best Regards,

Evan

Hello,

Thank you for your reply.

In this second case, it seems shortening the duration from GPIO glitch to RESET_N driven low allows the PHY to proceed with reset state machine without entering this stuck state. We have not characterized the behavior for this case, but it is acceptable if this timing is consistently observed and there are no functional issues.

For above, do you also have same idea as shown below ?
>please note we have not characterized this behavior.

BR,

Hi Machida-san,

That is correct. Please share any findings on customer side about failure rate or consistency when applying either of these workarounds.

Thank you,

Evan