AM625: Power up sequencing

Hello Justin Loundagin

Thank you for the query.

Please refer to the below errata.

Regards,

Sreenivasa

Thanks for that. My board doesn’t seem to apply to the errata, since it happens before data transfer. It is not even outputting C’s when waiting for data transfer.

Hello Justin Loundagin

Thank you.

If you could share the schematics i can have a check. Do you have an alternate boot mode to check other than the UART?

Regards,

Sreenivasa

Hello Justin Loundagin

Here are some quick check suggestions:

You need to check the voltage of all power rails, the state of all reset inputs, and confirm the device has a valid reference clock when it gets in the state. To confirm the device is receiving a valid reference clock, check the WKUP_CLKOUT0 pin to see if it is toggling at 25MHz.

Regards,

Sreenivasa

I cannot share the schematic, sorry.

All rails and resets look good. See my original post for the power sequencing capture. There is a 25 MHz clock on WKUP_CLKOUT0. I just don't see any output ("C") over the UART. I verified boot straps, and even scoped the UART0_TX line. I don't see any output.

I see "C" outputting over UART0 maybe 1-2% of all power cycles performed.

-Justin

Hello Justin Loundagin

Thank you.

Have you checked any alternat boot and does that work.

Can you share the boot configuration you are using.

Regards,

Sreenivasa

Unfortunately SD and Ethernet booting will not work due to hardware issues. I am now trying to get UART boot loading going so I can flash the eMMC.

SW1: 11011100

SW2: 00000000

Hello Justin Loundagin

Thank you.

Help me understand what SW1 and SW2 is representing.

Justin Loundagin said:

I am now trying to get UART boot loading going so I can flash the eMMC.

I guess the UART errata could limit this. Let me check.

Without the implementation information, we can provide limited support since this is a system level issue.

I assume you have done the same test with the UART and see this working.

have you tried the same on multiple board to rule out assembly related issues.

The below documents could help 

AM62X
www.ti.com/.../sprad05b.pdf
www.ti.com/.../sprad21c.pdf
www.ti.com/.../sprad06.pdf
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1280721/faq-am625-am623-am625sip-am625-q1-am620-q1-custom-board-hardware-design---faqs-related-to-processor-collaterals-functioning-peripherals-interface-and-starter-kit

Regards,

Sreenivasa

SW1 and SW2 are the same dip switches that were on the AM62x-SK eval board.

There seems to be an intermittent issue with the UART booting on all the boards. Some work more consistent than others, however the issue is still there.

Another data point is that the AM62x RESETSTATz goes low after being powered on for a couple minutes, and I am not sure why. We are using TPS65219 which the RESETSTATz connects to RESET / MODE and would cause a cold reset of the PMIC. I modified the registered to change this function to a warm reset, however I do not have a explanation on why RESETSTATz goes low after a couple of minutes.

Is there any specific ROM documentation that may include information on system timeouts / interrupts?

Thanks

Hello Justin Loundagin

Thank you.

The TRM includes all the available documentation.

Does the power supply continue to be stable when the Resetstatz goes low. 

WHat is the duration for which the RESETSTATz is low?

Regards,

Sreenivasa

RESETSTATz going low after about 1-2 minutes, and it stays low. It was causing the PMIC to turn the rails off, however I modified the PMIC registers to perform a warm reset. I am not sure why RESETSTATz is going low, however it is not my first concern, just a data point.

I am more concerned that there are no XMODEM Cs being outputted over UART0. What are your thoughts of the power sequencing / reset slew images that I posted?

Thanks

After reviewing the TRM more, I suspect the RTI WDT (Watchdog) is timing out at 180 seconds. This timeout is causing a warm reset on (RESETSTATz). This must imply that it is hanging somewhere in the initial boot process. I just need to figure out where and why...

I decided to go the USB DFU boot method, and I have that interface up (but buggy). After transferring the tiboot3.bin, I am faced with this output message over UART0

U-Boot SPL 2021.01-g2ee8efd654 (Feb 24 2023 - 05:59:23 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes

It seems to hang here and not accept the tispl.bin...

Hello Justin Loundagin

Thank you.

Let me check internally with the team.

In the meantime, i would suggest you review the implementation around USB device - VBUS divider, signals interface (no series resistors) etc and the eMMC interface i assume you are trying to access.

Regards,

Sreenivasa