AM625: Not able to boot some AM625 from u-SD card

Hi Mitesh,

Mitesh Hiran said:

Would it be possible to board from UART or USB just to test the hardware?

Do you have provisions on the PCB to modify the BOOTMODE pins?

Mitesh Hiran said:

We have tested all power rail on the board & all seems good. 

Can you please check XTAL clock and reset inputs and outputs rise to HIGH?

Thanks,

Stan

Thanks for your reply.

Yes we have dip switch on the board to switch boot pins [3:9]

Tested the XTAL is around 24Mhz on pins 23,24

Reset pin is HIGH, pin F20

Mitesh,

Thank you for the inputs.

Can you please tell all BOOTMODE[15:0] pin values including DIP switch and hard-coded pins?

For the resets, can you capture the reset status pins:

Thanks,

Stan

HI Stan, the two reset status pins are pull down and the status are HIGH for working board when powered on. 

and LOW on non-working board!! 

What could cause this please? 

In terms of the boot mode pins

Pin 0,1 are tied HIGH

Pin2 is tied LOW

Pin 3, 4, 5 are tied LOW 

Pin 6 : 15 are tied LOW

DIP switch pin 3 to 9 are connected and Boot pin 3: 9 (0001001 => for SD card boot)

Hi Mitesh,

There are several reset sources that can cause POR for the device. We can start with MCU_POR input pin. This is usually driven by PGOOD signal from PMIC or/and some other circuitry. Can you please check it as well?

Thanks,

Stan

Hi Stan, tested on both working and non-working board and on both boards D2 pin (MCU_PORz) is HIGH (1.78V)

Thanks 

Hi Mitesh,

There is one more pin input that may cause internal reset:

Mitesh Hiran said:

Tested the XTAL is around 24Mhz on pins 23,24

Can you confirm you are using 24-MHz crystal?

Thanks,

Stan

HI Stan, tested E11 (MCU_RESETz) and on both boards is HIGH 3.3V

Thanks 

Mitesh,

I'm looking forward for your feedback about the crystal/oscillator frequency you are using.

Thanks

Hi Stan, its 24MHz. 

part number ECS-240-30-30B-DU-TR

Thanks 

Hi Mitesh,

What I noticed is that BOOTMODE[2:0] pins do not correspond to 24-MHz crystal:

This setting tells Boot ROM code how to configure the PLLs during boot.

OH dear, sorry for confusion.

I rechecked this and the part used is 25MHz. 

This would be huge issue if the part was incorrect as we have built 20 systems and all worked well it's just this batch of 40 bards only 2 worked. 

The part is ECS-2520MV-250-CN-TR

Hi Mitesh,

Your BOOTMODE[2:0] pins are set to 25 MHz (see the snapshot from TRM) , and you have a 25 MHz crystal which is as expected in terms of ROM.

Mitesh Hiran said:

Would it be possible to board from UART or USB just to test the hardware?

Yes you can try UART boot on UART0 with the following BOOTMODE config:

You can find more details on UART boot in section 5.4.7 UART Boot in the TRM.

Regards,

Stan

Thanks Stan.

We wanted to try UART boot, just to see if there is an issue with booting from SD card.

Given that we now know the reason for the failure is the SoC is struck in reset stage, not sure if this would be helpful.

What kind of testing would you suggests for debugging why the SoC is stuck in reset stage please?

Thanks 

Stan, on some of the failed PCBA, the SoC is not in reset but the boot console just prints following and is stuck.. 

U-Boot SPL 2023.04 (Feb 13 2024 - 11:44:04 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes

Hi Mitesh,

It looks like something hardware here too.

So we got 3 cases:

1. Two boards boot Linux fine
2. Several boards start with 2 messages from u-boot, then hang. Can you confirm the status of the reset pins after the hang?
3. Most boards are stuck in reset

Is this correct?

Hi Stan,

correct.

On the boards where we get only couple of lines the SoC is not in reset, the 3 pins are high.

Hi Mitesh,

You mentioned now the new batch is with 25-MHz crystal while the old one was with 24 MHz. I think u-boot needs to get updated for 25 MHz.

Also, do you know for other hardware updates to newer boards?

Did you requested schematic review from TI?

Thanks,

stan

Hi Stan, no no original batch and this all have 25Mhz clock it was just I said it wrong before. 

Only item that is changed is added more EMC filters on the main 24V power rail and this we have removed to see if it had anything to do with the issue. 

No, we didn't request TI for any schematics review. 

Hi Mitesh,

I assume you are testing with the same software all the boards. Also the power supply is the same and it's adequate.

My thoughts are if the prototypes worked ok and the subsequent batch has issues, then it could be some fault at the PCB provider? Did you visually inspect the new boards for anything different, for missing components, poor solder joints, anything? 

How many of prototype boards worked ok? 100%?

Regards,

Stan

Hi Stan, yes, we are working with the PCB manufacturer as well.

We have x-rayed few boards near SoC and DDR and u-SD card and going through component to component review. 

we have more than 20 boards built and worked of prototype batch and pre-production batch.

The test setup, software, Linux OS, boot method all are exactly same. 

We had to use alternative SD card connector and DDR. and we have not see any issue with the alternatives but most of the boards fails to get out of SoC reset. 

And was hoping if you could suggest any more debug methods. (Thanks for pointing us towards reset review)

Clocks works, power rail is good, there is no external reset applied, DDR is from different vendor Alliance Memory instead from Micron but the part number and package ID are exactly same. SD card connector is the replacement recommended by the connector manufacture. 

It just that ONLY two worked and rest (38) failed points more towards the components issue. 

I have tried booting from UART using Tera Term, what serial software do you recommend to booting in UART mode?

I was able to get the tiboot.bin file transferred/booted but then failed to go ahead of SPL ... 

Hi Mitesh,

Have you first tested that "C" character is periodically printed (in 1-2 seconds) on the target UART port in the UART boot mode (power cycle the board after changing the boot switches) ?

Mitesh Hiran said:

I was able to get the tiboot.bin file transferred/booted but then failed to go ahead of SPL ... 

I am not a Linux / U-boot software expert, so I can not recommend some primary bootloader specific for U-Boot / Linux. Would you please explain the steps in which you transferred tiboot.bin over UART and booted the image. What are the messages in the console ? 

Regarding the UART boot mode I can recommend (loader from the MCU_PLUS_SDK_AM62x). First try to download the TI Uart_Uniflash image over the UART port (in case the "C" character test works). You can send the Uniflash image via the SDK available TI python script. The AM62x ROM loader will then load Uart_Uniflash flasher to RAM and launch it. The Uniflash knows how to flash SBL bootloaders, such as the SBL_NULL bootloader. The SBL_NULL image can be passed by the same python script over UART to the running Uniflash program which knows how to flash the bootloader  to the OSPI Flash memory (I hope you have an OSPI Flash memory on your boards). After a successful flash of the SBL_NULL bootloader, try to boot it. For this purpose switch the boot switches to select OSPI boot mode and power cycle the board.

For a detailed explanation please refer to the Section, Flash SOC Initialization Binary of this guide: AM62x EVM Setup

The Boot Modes are also covered in the Section, AM62x SKEVM User Setup/Configuration / subsection Boot Modes of the guide: AM62x SK Evaluation Modules

I am not a Linux expert and do not know how useful would be the below AM62x LINUX SDK documentation for your usecases:  

AM62x Linux quick startup guide

Let us know if you have questions.

Thanks

Kind Regards,

Anastas Yordanov

Hi Anastas, Thanks a lot for details.

I have configured the boot modes for the AM6254 SOC to UART and on power up on Tera Term, I have set to 115200 baud rate and I see 'C' printed at regular interval after some initial hexadecimal numbers. 

I then sent 'tiboot3-am62x-gp-evm.bin' file that we have and works when booted from SD card. (All boot files are exactly same as the working SD card boot files)

After the file is sent we get following messages :

U-Boot SPL 2023.04 (Feb 13 2024 - 11:44:04 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)')
SPL initial stack usage: 13384 bytes

after this point, we don't get 'C' printed and nothing happens when I transfer send file 'tispl.bin'

if this would have worked I would have sent the last 'u-boot.img' file.


Thanks

Hi Mitesh,

we may need to further discuss with a TI SPL / u-boot software expert for further hints on how to continue the analysis.

Please ping this thread if you do not get a response early next week.

Thanks

Kind Regards

Anastas Yordanov

Thanks a lot, Will do.

Hi Mitesh,

This looks like DDR initialization issue. Can you please check Section 2 in this FAQ? 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1358039/faq-board-bring-up-tips-for-sitara-devices-am64x-am243x-am62x-am62l-am62ax-am62d-q1-am62px?tisearch=e2e-sitesearch&keymatch=uart%2525252525252520boot#

Other sections in the FAQ may also help.

Regards,

Stan