AM4372: Custom board boot issues

Are you sure that SYSBOOT[4:0] = 00001b? This corresponds to boot sequence MMC0 -> MMC1 -> USB_MS (USB1) -> USB_CL (USB0). There is no UART boot in this sequence, that will cause printing of "C" characters. Are all of the SYSBOOT pins tied high, resp. low? No SYSBOOT pins should be left floating.

Hi Biser,

All SYSBOOT pins are tied low except for SYSBOOT 0 and SYSBOOT14. Done with resistors as per EVM design.
At this point we only have SDCard inserted (MMC0), no image on eMMC memory (MMC1) yet. We do not intend to ever boot from USB, will eventually be MMC1 (there is no option for only MMC0 and MMC1 thus the options with USB). Should we rather use a different config for now ?

Thanks

SYSBOOT seems OK. Do you have any software on the SD card?

Yes, 3 partitions on SD Card
Partition 1 is boot with MLO and UBOOT,
Partition 2 is RFS with TI Arago Linux,
Partition 3 is for custom code.

If I press the reset button the card boots perfectly every time.

Further to previous information:

I measure PORZ -> high to RESETIN_OUT -> high as ~24ms upon power-on. Thereafter when I press reset push button I measure this period as ~100us. Upon power-on the CPU never boots, whereas it boots successfully every time upon reset push button.

Further to previous information:

I have an AM437x Evaluation Module that I use for comparison purposes.

I notice on this EVM that the time from 3.3V reaching around 80% of 3.3V to POR -> high is ~24ms. This leads me to believe the TPS65218 has PGOOD delay left at default of 20ms.

On my custom board I measure a similar time (PGOOD delay also left at default). Yet my board does not boot.

If I reprogram this PGOOD delay on my custom board to 150ms, my board boots every time.

This solves the problem, but I need to understand why this is the case, surely something else must be a problem on my board.

I further notice that when my board does not boot (ie PGOOD delay is at 20ms), the 24MHz clock is output continuously on both pin C24 and pin D24.

Further to previous information:

Using the JTAG Debug Probe to read back the CTRL_STS register when the processor does not boot reveals that the SYSBOOT bits have the incorrect value, i.e. not as set up with the external resistors. These incorrect bit values seem to be random values, i.e. they are different each time the processor does not boot.

Again, when measuring with an oscilloscope, each of these SYSBOOT signals are stable at the correct voltage value (+3.3V) for at least 20ms prior to PORZ->high.

Louis, here are a few ideas:
-what IO voltage do you have the pull ups connected to on the boot pins? It should be the same node as VDDSHV6 on the processor
-have you checked that POR is low all the way through the power on sequence and only transitions high once after all power rails and oscillator are stable? Maybe a glitch in POR is causing the unexpected results in the SYSBOOT latched values.
-ensure all voltage rails ramp correctly and are stable by the time PORz goes high. Use a scope to ensure no droops or glitches in any of the supplies, especially IO voltages and VDDS. The fact that you can boot by toggling reset certainly points to some anomaly in your power sequencing or voltage levels right around POR getting deasserted.

Regards,
James

Thank you James.
Agreed, my feeling is the same about the power rail being unstable at PORZ->H. Have not yet been able to see such event on the scope.
I am wondering what is happening inside the processor, with the clock. How can I see if the internal oscillator circuit has started correctly ? Even if SYSBOOT[17] is strapped accordingly, surely it must first get sensed at PORZ->H and then some time thereafter CLKOUT becomes available. So internally it is probably 'ready' much earlier, and the question is whether it is 'ready' early enough for proper startup - how can I check this ?
Louis

Hi Louis, you can check the clock is getting through the device by setting the SYSBOOT17 as you say and monitor the CLKOUT1 signal.  You should see the clock when POR gets deasserted.  I don't think there is a way to check the internal clock while POR is asserted.  Once again, i think checking all voltage rails around power sequencing is important, especially VDD_CORE and IO voltages and VDDS.     

Regards,

James