AM62A7-Q1: How can I obtain the reason for the restart?

Hi Expert,

can you help look into this thread?

BR,

Biao

Hi Qingzhe,

As aligned offline, I have provided some guide to you already, we can find the reset reason from below register: WKUP_CTRL_MMR1_RST_SRC;

and I also provide the this to you to SW reset the device.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1237209/faq-am64x-how-to-reset-warm-reset-the-soc-from-software?tisearch=e2e-sitesearch&keymatch=warm%20reset#

I think your real question is, when you trig the SW reset there is no record in WKUP_CTRL_MMR1_RST_SRC, Right? and this register will be always 0.

either the SW reset or PMIC WD reset, you want to know how to record the SW reset.

Hi Anil,

I have clarify the question from customer to you, pls help have a check.

BR,

Biao 

Hi Biao && Anil

Yes, I just want to obtain the correct reason for the restart so that I can analyze the problem later. Also, I would like to know the detailed meaning of each reboot reason reflected in this register? Where can I obtain a detailed description? The descriptions here are very brief and I don't quite understand their meaning

BR,

Huang

Hi Huang,

The subject matter expert is out of office this & next week. So responses to this thread will be delayed. Thanks for your patience.

Meanwhile the details to the above reset type can be found in section 6.3.5 Reset Details of the TRM.

Regards,

Tushar

Hi Tushar

Could you please help me deal with this issue as soon as the expert returns, or are there any other experts who can assist me during his vacation?

BR,

Huang

Hi Huang,

Can you please tell us which specific part of reset you did not understand or is not clear?

If you are unclear, what each bit in the register means, please refer TRM section 14.2.1.1.3.258.1 WKUP_MMR0_WKUP_CTRL_MMR0_RST_SRC for details.

Please refer below screenshot.

Please also refer 6.3.3.1 Reset Status Register

Regards,

Tushar

Hi Anil

I would like to ask, after calling the Scicontent_pmDeviceReset() interface and then using SOC_getWarmResetCaseMainDomain() to obtain the reset reason, I always read 0 instead of showing it as a software reset. I am very confused about this, may I ask why?

BR，

Huang

Hello Huang,

Regards,

Anil.

Hi Anil

I didn't clear the reason, I just called the SOC_getWarmResetCauseMainDomain() interface directly to read its return value and print it out, but the result printed out was 0. When calling the Scicontent_pmDeviceReset() interface, the machine will experience a restart, so I believe it is effective.

BR,

Huang

Hi Anil & Biao

I conducted an experiment where I called Scicontent_pmDeviceReset() every 30 seconds to perform a software hot reset while the car computer was not powered on. After the reset, I read the reset reason through SOC_getWarmResetCauseMainDomain(). However, after each software reset, the read restart reason showed different situations, as shown below. Sometimes it indicated that the reset reason was a cold reset, and sometimes it indicated that the reset reason was a software reset. What is the reason for this?

BR,

Huang

Hello Huang,

As per the above results, your understanding is correct.

The SOC went through sometimes POR and WarmReset.

If the above Register values are zero, then definitely your application is doing the POR only and there are other possibilities.

And this register will never be cleared in other than POR.

See if this POR is coming from the PMIC or HW MCU_PORz pin.

The link below is helpful to debug your reset issue further and follow the steps below as per the debug guide.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1421267/faq-am6x-device-reset-troubleshooting-document

Regards,

Anil.

Hi Anil

I followed the guidance you provided and measured the MCU_PORZ pin. As you said, when the MCU_PORZ pin undergoes a high to low level transition, the value of the register I read is 0. However, when there is no high to low level transition, the reason for the reset I read is software warm reset. This seems to meet your expectations, but I have a question: why does the MCU_PORZ pin sometimes undergo high and low level transitions, and sometimes not? Is this a normal phenomenon?

BR,

Huang

Hello Huang,

?? ? said:

Is this a normal phenomenon?

This is not normal behavior.

The MCU_PORz pin is an input to the SOC and the SOC can't drive any signal on this pin.

If this pin is changing from high to low or low to high, then look at your system and this pin is controlled by any other external devices such as PMIC or any external SOC/Microcontrollers/FPGA  driving this pin. Other than this, there is no way SOC drives this signal.

And, I hope you also confirmed the above results on this below highlighted pin only.

Regards,

Anil.

Hi Anil

I have confirmed that there is no other control for this pin, it is only connected to NRSTOUT of PMIC.
I did some other tests, but instead of calling Scicontent_pmDeviceReset() to trigger a restart, I entered the reboot command on the SOC side to restart it, and then read the value of the MCU_CTRL_MMR0_SSTSRC register. I performed three reboot operations, one of which resulted in 0x00010000 and two resulted in 0x0000000. At present, it is still unclear what caused it.I hope you can provide some testing suggestions to locate the problem.

BR,

Huang

Hello Huang,

If this MCU_CTRL_MMR0_RSTSRC content is zero and the MCU_PORz input is changing from high to low, then the SOC is going through POR and there is no other possibility.

Is it possible to disconnect the PMIC with an MCU_PORz pin and I assume that the signal is changing on the MCU_PORz is due to  the PMIC.

Make sure that we need to drive high on this pin by default, after disconnect the PMIC from MCU_PORz input.

Regards,

Anil.

Hi Anil

After disconnecting the MCU-PORZ pin from the PMIC and pulling it up, I also took the operation of inputting the reboot command into the SOC serial port, but the reason I obtained was still a cold start reset.

BR,

Huang

Hello Huang,

Can you please share which is the command you are giving ?

What is the register you are reading ?

Please give the above details.

Regards,

Anil.

Hi Anil

Yes, the command I input on the SOC serial port is "reboot". Press enter to execute the command, and the car system will restart. After the car system restarts, I use the "devmem2 0x04518178" command to read the value of the MCU_CTRL_MMR0_RST_SRC register, as shown in the following figure

BR，

Huang

Hello Huang,

Please share the MCU_PORz pin connection details as well .

In the above comments you confirmed that you disconnected the MCU_PORz input from the SOC.

Share the Pin and schematic details as well.

Regards,

Anil.

Hi Anil

OK,The following diagram shows the connections related to the MCU-PORZ pins before we made any modifications.

Based on the testing feedback you provided, we made the following modifications: removing the resistors R0408 and R0411, and adding a 1.8V pull-up to the MCU_PORZ pin.

I hope the above information can help you.

BR，

Huang

Hello Huang,

I am looking at your reply and you may expect reply in one or two days .

Regards,

Anil.

Hello Huang,

I did analysis on the above points.

I don't think, other than the power supply glitches, there is no possibility of SOC POR.

please share the waveform of A7 input after removing the above R0408 and R0411 Resistors and connect to pull up the Resistor.

Did you have any glitches in the power supply which you connected to the SOC ?

Please monitor the waveform of the power supply of SOC and share the waveforms.

Regards,

Anil.