Soft-Reset of AM335x causes eMMC boot not to function

Jason,

Thanks for using E2E!

I'm not sure of your design, but are you perhaps using an LCD or another peripheral with the AM355x here?

The reason that I'm asking is because some of the LCD signals are muxed with the SYSBOOT pins. This could explain why your boot sequence seems to change.

For cold power-up, the LCD signals may not be powered up yet when the SYSBOOT pins are read.

For warm reset, the power may not be turned off to the LCD signals, which changes the SYSBOOT pins when they are read compared to cold power-up.

More information related to this can be read in another post (https://e2e.ti.com/support/arm/sitara_arm/f/791/p/272718/952431

We are indeed using the LCD-output of the pins, which then begs two spec' questions.

1. During a system restart (MRESET cycles low), are the GPIO Pins of the LCD/SYSBOOT supposed to go Hi-Z (allowing them to take the SYSBOOT configured state). The Family datasheet 2-7 suggests that on "Reset Rel State" these go to 'Z'.

2. So if we assume the datasheet is somehow misleading, what would the plausible fix for this?

3. If we assume the datasheet is correct and we're going to Hi-Z on these pins during MRESET, then why would we be interpretting a different mode SYSBOOT Mode (which is a plausible explanation to UART over eMMC) ? (I'm confident the LCD is not driving these pins, as they are pure data inputs, and I'll confirm we've tested this with no LCD physically connected)

Hi Jason,

While you're confirming that the test was done with no LCD connected, here are some other links that may be helpful.

1) Values of pull-up/pull-down resistors for SYSBOOT pins (https://e2e.ti.com/support/arm/sitara_arm/f/791/p/257637/901559

"You need to consider the worst-case internal leakage current possible for each IO and size your external resistors such they will be able to pull the signal above or below the valid logic levels defined for the respective IO. If other devices are attached, you may need to add their internal leakage to the AM335x internal leakage when calculating the maximum resistor value required to pull the signal to the worst-case valid logic level of all attached devices."

2) Signal conflict (https://e2e.ti.com/support/arm/sitara_arm/f/791/t/355238#pi316653=2

"Another signal conflict occurs on A0-A11 pins, as they are connected to a network PHY via RGMII2 interface. In this case two outputs work against each other during XIP detection phase."

3) SW Booting Configuration (https://e2e.ti.com/support/arm/sitara_arm/f/791/p/252225/884475

"I think about SW Booting Configuration:

a) When the cold reset(PORz) is occurred, the SYSBOOT pins are re-latched. 
b) When the warm reset(nRESETIN_OUT) is occured, the booting starts by reading the control_status register without latching the SYSBOOT pins."

4) Minimum Reset Time & SYSBOOT pins latching time (https://e2e.ti.com/support/arm/sitara_arm/f/791/t/324739

"The PWRONRSTn terminal may need to be held low long enough allow the SYSBOOT inputs to be pulled to their valid logic levels. Therefore, the minimum reset time also has a system dependency related to pull-up/pull-down resistors values and respective signal trace capacitance of each SYSBOOT input."

"This isn't stated anywhere in the documentation. There is a simple measurement you can do: If you tie SYS_BOOT[5] = 1 then you can measure the time from PORz rising edge to first edge of clock appearing on the CLKOUT1 pin. This would mean that the SYS_BOOT value is latched and processed, and will be the maximum hold time for SYS_BOOT pins."

The datasheet should be correct about High-Z during reset, but I'm wondering if the default mux mode (Mode 7) for pins like GPIO2_6/LDC_DATA0 may be a factor here. There could be a conflict on these pins during the mux mode change from SYSBOOT to LCD.

Hope this helps! I will loop factory in here.

James

- I have confirmed that our LCD is not currently connected (So the only thing connected to our SYSBOOT pins are the pull up/dn resistors.

1. Noted leakage current for 3.3VDDS GPIO is 5uA.  We had 100K resistors onboard, which would look like 0.5V in worst case.

2. Not sure how this relates to our problem... At this point LCD_DATA0-15 are solely connected to our pu/pd resistors only.

3. We are resetting via (PORz), so we should be latching appropriately.

4. The problem exists for horever long we hold PWRONRST (MRESET) Low.  (if we hold it low for a couple of seconds, but power remains on, same problem).

 

We did change the Pu/Pd Resistors from 100K to 10K, and this has (tentatively) shown positive results.  This value change though doesn't give me confidence that I've 'understood' the problem, and reliably resolved it.

Hi James,

I can recommend checking the 3V3 rail during reset. Another thing that can help is reading the value of the control_status register.

P.S. I will move this thread to the Sitara forum.

Also I would check your setup closely as what you are describing is NOT how the BBB (rev c) works.

You can easily test. If you hold the user button down with valid eMMC contents and a valid bootable SD card in place.

Power up it will boot from SD card. If you then push reset button (by itself, user button released) it will still reboot from SD card.

Likewise (same setup) and power up without user button pressed, it will boot from eMMC. (even with valid bootable SD card inserted).

Pressing reset will again reboot from the eMMC.

I am using 3K3 as PU/PD resistors. There seem to be a weak pullup inside the chip, and I want to reliable override it. (External pulls should be stronger than internal).
Note that there is an additional reason to choose strong pullup/downs: the wire to the LCD is long, and a weak pull does not offer sufficient protection against induced EMI.