Not asserting RESETIN_OUT on beaglebone

Hey Gunter,

Paul and I investigated this on the EVM, and we were seeing the same issues.  The main problem on the EVM was the 1uF cap close to the warm reset pushbutton that was keeping the voltage high.  The drive strength of RESETIN_OUT was simply not strong enough to discharge this cap for the RSTTIME (configurable to a max of 10us).  After we removed this cap, we saw better results, but ultimately we had to also remove connection to an RC circuit going to the JTAG to get an expected waveform, which should be RESETIN_OUT driven low (for time determined by PRM_RSTTIME), then the pull up takes over to pull it back to a high level.

On the beaglebone, I believe this 1uF cap is also present.  If you remove this, you should get expected results (the other circuit going to JTAG is not present on beaglebone).

A couple of warnings when using RESETIN_OUT:

-PRM_RSTTIME register value set timers that are clocked by the high frequency system clock (24MHz, for example).  The max times this register can delay the RESETIN_OUT release is around 10us.  This is way to short relative to any possible pushbutton warm reset input event.  This will cause the device to start boot up well before the warm reset signal is deactivated, which could potentially cause boot failures if the warm reset is connected to a boot peripheral.

-RESETIN_OUT should not be used as both an input and output.  It can be used successfully as an input only (warm reset push button), or an output only (to reset peripherals), but not both.  The issue you have seen reinforces this fact.  A cap used with a pushbutton for debouncing a warm reset button press will negatively affect the RESETIN_OUT output signal driven by the device.

Another issue we found is that using RST_GLOBAL_WARM_SW gave us a max low going pulse of around 10us (with PRM_RSTTIME set to maximum).  Setting the RST_GLOBAL_COLD_SW only gave us a max pulse of around 660ns.  I'll have to get with the designers to see why there is a difference.

I checked the Ethernet PHY datasheet, and the minimum pulse on its reset is 100us.  So using either software reset will not adequately reset the Ethernet PHY.

Regards,

James

James and Paul,

the customer has isolated the RESETIN_OUT pin from the rest of the circuitry, i.e. removed the connection to the nRESET on the PHY and removed the connection to the JTAG EMURST, removing the resistor off the RC circuit, so the 0.1uF cap is not affecting the behavior anymore. Still they are not seeing the RESETIN_OUT pin get asserted on warm reboot. There is nothing else on the pin per their schematics.

Regards,

--Gunter

Gunter, have them maximize the values in PRM_RSTTIME before triggering a software reset.

regards,

James

James, I told the customer that just a little while ago, waiting for feedback.

The conf_warmrstn is set to 0x28. Is that correct? Looks good to me.

Thanks,

--Gunter

This output is open drain.  They will need a pull-up resistor.

Regards,
Paul