AM62A3: AM62A3 Abnormal Bootup after POR reset

Hi Wang

Is it possible on your board to choose another boot option like e.g. USB to test if it works?

Unfortunately UART is not a reliable option in this SoC. Please refer to errata:

Regards,

Stan

HI Stanislav 

thank you .  UART boot is not our expectation .  this issue is  when we reset SOC , the SOC enter into UART bootmode which is not we need .

we want to know why this happened .  because  it should just reset and  bootup from flash again .   but sometimes it doesn`t  boot as we want . 

Is it cause by Flash ? how can we verify it ? 

thank you . 

Can please share your BOOTMODE pin settings?

hi Stanislav 

there is abnormal signal on  BOOTMODE PIN .  because we find that the SOC read the Flash and get the FLASH ID answer  after POR reset release .

the SOC try to read flash ,This means BOOT PIN is OK . 

attache file is the RESET and QSPI flash sequence .  you can see that there are no QSPI signal afterSOC get ID feedback from flash . 

why does this happen ? 

the reset logic is  :  when SOC get command "reboot" , then SOC will not feed the WDOG of PMIC TPS65224 .  and simultaneously , SOC reset itself softly and PMIC pull PORZ of SOC low  and release.

Reset—QSPI sequence.docx

Meeting minutes :   

1, TI help to check if all the register are reset to default when MCU_PORZ is low 

2, Developer  read the BOOTMODE pin vaule through JTAG TOOL .  (remind :as the SOC is reading flash and get feedback , the bootmode should be already  configed right  )

Hi,

I'm not sure why ROM is issuing Read ID multiple times.Looks to me like ROM fails to validate the image at address 0x0 then re-tries at 0x4000 0000 and also fails.

MCU_PORz pin reset is a fundamental cold reset. It resets the SoC like it is starting from Power-On.

Yes, reading BOOTMODE pins from CTRLMMR_MAIN_DEVSTAT[15:0] register is a good point.

Stan

HI Stanislav 

more information for you . when the soc fail to bootup from flash . we manually pull PORZ to low ,and release to high , the SOC also retry to communicate with flash ,and fail to bootup .  its behavior is the same with the issue case .   we had tried several times .  

it can be normal only when we cut off the power supply and power on again . 

another test with below sequence :

1, when the soc fail to bootup from flash . we cut off the 1V8 supply of flash , it means  flash is power off . 

2, and then we re-contact the 1V8 supply of flash , the flash is powered on . 

3, than , after we pull PORZ to low and release to high , we can see soc is trying to read flash ,and flash feed back ID .

4, but at this situation , the SOC is also booting up fail from flash . 

Hello Wang Dong,

Thanks for the updates. We are going to further discuss with Stan tomorrow. 

wang dong said:

more information for you . when the soc fail to bootup from flash . we manually pull PORZ to low ,and release to high , the SOC also retry to communicate with flash ,and fail to bootup .  its behavior is the same with the issue case .   we had tried several times .  

it can be normal only when we cut off the power supply and power on again .

I have one question and one request:

Q1: Does your QSPI NOR Flash memory have a hardware reset pin. If yes, is it connected in the same or similar way as it is done on an TI AM62A SKEVM like SK-AM62A-LP ? 

Q2: Would you please provide a schematic of the complete hardware interface between the AM62A3 SoC and the QSPI Flash memory + the PMIC and relevant power supplies and PMIC connectivity to the AM62A3. If it is NOT possible for you to disclose here, please feel free to provide to me per private E2E message ?

Thanks in advance

Best Regards,

Anastas Yordanov

Hi Anastas 

message was sent to you . thank you .

Hi Stanislav  

I agree with you that PORZ is a cold reset .  but when I pull low to high for this PORZ ,  the SOC is still in this abnormal status , it can not jump out from it . 

but when i  cut off the power supplies from PMIC , the SOC is totally power off , and then re-power on the PMIC , the SOC can boot success .

what the different for PORZ and POWER ON in this case ?   why there is different result for a cold boot ?

CCS_JTAG_LOG.zip ，HI Stanislav ，Anastar 

here are the log from JTAG , plz help to check what is wrong with it  ?  thank you . 

Hello Wang Dong,

Thank you for the provided schematic and QSPI Flash memory documentation.

Did you have the chance to capture the MCU_PORz with oscilloscope in case of your manual PORz de-assertion ?

I will analyze your inputs and try to respond by early next week June-15 COB. 

Thank you

Best Regards,

Anastas Yordanov

The rom log and trace only show what we were already suspecting. ROM tries to read the data from flash:

1st at offset 0x0

2nd at offset 0x400000

Then it switches to the backup boot mode which in this case is UART.

The DER warning shows that the data read from flash was not recognizable.

Can you confirm what flash part  is using?
As stated some QSPI flash vendor may not have an input reset pin, therefore only an actual power cycle would reset the flash.

Thanks.

Linjun

hi Meng 

As we discussed in the meeting ,  I cut off the supply of 1V8 which input to flash . and then re-contact it to flash . this action is more like to reset flash .  after that ,we pull PORZ low and release to high , this is more like SOC reset  and initial to read flash . 

But , this error is still occurred .  so  it is not caused by no reset of flash  . 

thank you . 

The root cause from ROM log is the flash was not recognizable.  

hi Anastas,  Please take the waveform as reference. The first de-assertion is mannually pulled down. The second de-assertion is 10ms.

Here is the detail parsed log.

ROM tries to read the data from flash:

1st at offset 0x0

2nd at offset 0x400000

Then it switches to the backup boot mode which in this case is UART.

The DER warning shows that the data read from flash was not recognizable.

-----

Device AM62A rev R10

R5 LOG

Log magic: 0xcec9911e

Warning Log:

Log Max Index Size: 21

Log current entry: 4

Log buffer: 0x43c3e480

0: main.c:1397 ecode: 0x2010018, ts: 445

"Main_derPanic()!!!"

1: main.c:1752 ecode: 0xffffffff, ts: 450

"derOneParse() failed"

2: main.c:1397 ecode: 0x2010018, ts: 679

"Main_derPanic()!!!"

3: main.c:1752 ecode: 0xffffffff, ts: 683

"derOneParse() failed"

Severe Log:

Log Max Index Size: 21

Log current entry: 0

Log buffer: 0x43c3e680

Critical Log:

Log Max Index Size: 10

Log current entry: 0

Log buffer: 0x43c3e880

R5 Function Trace

Trace magic: 0x1cec8811

Trace Buffer Size: 21

Trace next entry: 8

Trace Disable?: 0

Trace Depth: 2

Trace tickfn*: 0x4180cb17

Trace buffer: 0x43c3ec00

0: Main_ospiOpen(0x43c3f298, 0x13880, 0x0, 0x0) did: 1 ret: 0x0 ts: 644 647

1: derOneParse(0x60400000, 0x7fffffff, 0x4180caf9, 0x4180cb1d) did: 1 ret: 0xffffffff ts: 659 682

2: Main_ospiClose(0x43c3f298, 0x13880, 0x60, 0x0) did: 1 ret: 0x0 ts: 687 691

3: Main_oqspiBootDataFail(0x43c3f298, 0x78001fb0, 0x78001fa0, 0x4180cc29) did: 1 ret: 0x0 ts: 695 698

4: pllMmrConfig(0x43c3f4a8, 0x5, 0x190, 0x4180cba1) did: 1 ret: 0x0 ts: 700 728

5: Main_mainBlockInnerLoop(0x43c3f498, 0x78001fc8, 0x1, 0x4180cc29) did: 0 ret: 0x0 ts: 771 0

6: Main_uartInit(0x43c3f498, 0x15, 0x4180f5f5, 0x0) did: 1 ret: 0x43c3f498 ts: 774 2477

7: Main_uartOpen(0x43c3f498, 0x1d4c0, 0x78100b78, 0x0) did: 1 ret: 0x0 ts: 2479 2558

8: (0x43c3f498, 0x0, 0x190000, 0x190000) did: 1 ret: 0x0 ts: 118 125

9: (0x41829a7d)(0x1, 0x1, 0x0, 0x0) did: 1 ret: 0x0 ts: 134 141

10: Main_warmStart(0x0, 0x1, 0x0, 0x0) did: 0 ret: 0x0 ts: 143 0

11: Main_delay(0x0, 0x78001fa8, 0x4180a544, 0x43c3f298) did: 1 ret: 0x0 ts: 149 152

12: pllMmrConfig(0x43c3f2a8, 0x5, 0x190, 0x4180cba1) did: 1 ret: 0x0 ts: 154 191

13: Main_mainImageInnerLoop(0x43c3f298, 0x78001fb0, 0x0, 0x4180cc29) did: 1 ret: 0x2 ts: 272 462

14: Main_ospiInit(0x43c3f298, 0x15, 0x41811b99, 0x0) did: 1 ret: 0x43c3f298 ts: 275 402

15: Main_ospiOpen(0x43c3f298, 0x13880, 0x0, 0x0) did: 1 ret: 0x0 ts: 405 410

16: derOneParse(0x60000000, 0x7fffffff, 0x4180caf9, 0x4180cb1d) did: 1 ret: 0xffffffff ts: 424 448

17: Main_ospiClose(0x43c3f298, 0x13880, 0x60, 0x0) did: 1 ret: 0x0 ts: 455 459

18: Main_oqspiBootDataFail(0x43c3f298, 0x78001fb0, 0x78001fa0, 0x4180cc29) did: 1 ret: 0x1 ts: 464 467

19: Main_mainImageInnerLoop(0x43c3f298, 0x78001fb0, 0x0, 0x4180cc29) did: 1 ret: 0x2 ts: 521 693

20: Main_ospiInit(0x43c3f298, 0x15, 0x41811b99, 0x0) did: 1 ret: 0x43c3f298 ts: 524 641

Hi All, 

FYI, based on the discussion yesterday with the ROM team, there are some test cases that were suggested to be done on the customer side.

We are waiting for the updates.

Regards,

Sreenivasa

Hi All, 

Adding meeting notes for wide audience.

From: Mandela, Venkateswara Rao
Sent: 15 June 2026 21:14
To: Meng, Linjun; Parrot, Benoit; sitara_rom@list.ti.com - Mailing list for Sitara ROM team (May contain non-TIers); Saikia, Juganta
Cc: Zhang, Yong; Tan, Ryan
Subject: Re: Customer report AM62A3 warm reset failed and enter UART Boot mode

Linjun,

Can you please try two experiments ?

1. Send the RESET command to flash (66h + 99h) as described in flash data sheet before issuing PMIC reset.
2. Set the backup boot mode to NONE. This will cause ROM to retry SPI boot multiple times without waiting for 120s UART timeout. We can get more data points.

Please copy other team members as required.

Regards,

Sreenivasa

hi Kallikuppa 

these two experiments were done . 

1, implement the flash reset (66+99) before PMIC reset , It is still in error status with boot fail . attached the data waveform .

2,Backup boot to NONE ,and implement the flash reset (66+99) before PMIC reset, we get the log . attached .  

backup mode changed to none.zip

Hello Wang Dong,

Thanks for the provided new inputs !

Best Regards,

Anastas Yordanov

Dear all,

Summarize the issue here.

Below is the Data view from OSPI Controller:

    normal state

      after reset 

During normal startup, the bitboot3.bin header matches the view from OSPI Controller.
However, after the system runs and resets, the first four bytes look strange.

To determine whether the FFEEEEEE value is read from OSPI Flash or not, the full QSPI trace is needed.

If the data is from nor flash, the next action is to find a solution from the flash view on how to set the status to
an uninitialized state.

If the data is from OSPI controller, the OSPI controller also needs to be reset.

HI Meng 

here are the data captured on 6/17 .  it is the same with previous part .

plz help to check .

all the other raw data  were sent with Email .

thank you

nomarl boot_Reboot_bySequency_FlashData_trace.docx

Only_reboot_dataTrace.docx

Hello Dong,

Thank you for the inputs.

The team is reviewing the inputs internally.

Regards,

Sreenivasa

Hi Dong，

     We performed a failure log analysis today and should be able to explain why the 0x6000_0000 view shows FFEEEEEE. Below is a waveform picture of when the failure occurred. Regarding the ROM reading the flash: the flash is in 4-byte mode, but the ROM is reading it in 3-byte mode. As a result, the OSPI controller will interpret the fourth address byte as dummy data and treat the dummy data as the first words from the flash—although this doesn't perfectly match the observed waveform.          

    To fix this issue, ensure the Flash is in 3-byte mode when booting from ROM . My suggestion is to software reset the Flash and close the controller before the PMIC timeout, then wait for the PORZ reset.

  If we encounter any boot-up stability issues, I suggest we analyze them one by one. Thanks.

Best regards,

Linjun

     Thanks a lot for joining the meeting with the flash vendor today. With the captured log analysis, we clarified the following issues:

1. Following the sequence of reboot and PORZ reset, the system cannot boot up because the Flash is in 4-byte mode.
2. The previous test sequence—power off the flash, then power on, and PORZ reset—still resulted in reboot failure. The root cause is that the power off doesn't cut off power, so the flash remains in 4-byte mode, causing the startup issue.

  To fix the issue:

      Solution 1: Keep the QSPI FLASH in 3-byte mode permanently. When accessing addresses larger than 128MB, use the 6C command directly in SBL stage 1 and SBL stage 2. @Saxena, Karan—could you please confirm whether the OSPI Interface

  avoids calling the B7 command (enter 4-byte address mode) and instead uses the 6C command (4-byte address read command)?

    Solution 2: Follow the TRM spec and connect the NOR flash reset pin to PORZ.

/cfs-file/__key/communityserver-discussions-components-files/791/DS25M4CB_2D00_16A1B6_5F005F00_Rev04.pdf

The QSPI flash datasheet.

/cfs-file/__key/communityserver-discussions-components-files/791/ti_2D00_flash_2D00_4byte.txt

This is the failure log after we disabled B7 command.

Attached is our example.syscfg.example-syscfg.zip

Hello Zhou,

Thank you for your response.

Please expect a delay in Linjun's response.

Thank you for your patience!

Best Regards,

Borsilav Lazarkov