DRA829V: Ball state at MCU_PORz reset

Anyone?

Hi Bo,

I probed this pin on one of our EVMs and it remains floating even after asserting a MCU PORz. I did not observe the pin drive low even with a pull-up resistor.

Can you please clarify when you are seeing this issue?

A. This issue occurs when performing a cold boot (power cycling the board)
B. This issue occurs when asserting MCU PORz after the SoC is already running

Additionally, can you please confirm if the SoC power-up sequence, specified in the datasheet, is being followed?

Are you seeing this behavior on all your boards?

Thanks and regards,
Mark

Hello Mark,

A. No. Power cycling brings back the device when hanged. We have tried to use the PMICs to toggle power but that brought other problems. We really need to understand how to perform a correct MCU_PORz that resets the SoC properly.

B. Yes, correct.

I will check the state machine of the STM32 that controls the reset procedure.

I have seen this on all the boards I have tried, 5-10 pcs, while working at getting U-Boot 2024.04 to work.

Regards,

/Bo

Hi Bo,

Can you provide the PADCONFIG31 (0x00011C07C) register value before and after asserting MCU_PORz?

Regards,
Mark

Hi Mark,

The register read-out:

=> md.w 11c07c 1
0011c07c: 0007                                     ..

Obviously I cannot read it when the device is in a hanged state.

The power-up sequence is good. Booting always works coming from power off. For the reset sequence we assert MCU_PORz, strap the desired boot mode (dfu or SPI NOR) and after 100 ms we deassert MCU_PORz which will bring the device out of reset.

Regards,

/Bo

Hi Bo,

Understood about not reading device when hanged. Thank you for checking the power-up sequence.

Can you report the entire 32-bit register value using md.l? I'm interested in bit 21 (TXDISABLE). I'm assuming this bit is being set to 0 in your software to drive STM32_NRST. Upon device reset (MCU_PORz included), this bit is set to 1 and the transmitter on the pin is disabled.

And to make sure I understand correctly, this is the sequence you're trying to accomplish?

1. TDA4 running
2. STM32 asserts a MCU_PORz
3. STM32 straps a boot mode
4. STM32 deasserts MCU_PORz
5. TDA4 asserts STM32_NRST (?)

At which step is it intended for the TDA4 to drive the AF21 pin low and assert a reset on the STM32? I imagine after step 4 otherwise steps 2-4 cannot be performed. If the TDA4 SoC is asserting STRM32_NRST before step 2, then I don't see how a MCU_PORz is being performed (assuming they're controlling each other's reset lines).

If we confirm the MCU_PORz is happening, can you isolate the AF21 pin from the STM32 and report if the pin still drives low?

Hi Mark,

Mark L. said:

Can you report the entire 32-bit register value using md.l? I'm interested in bit 21 (TXDISABLE). I'm assuming this bit is being set to 0 in your software to drive STM32_NRST. Upon device reset (MCU_PORz included), this bit is set to 1 and the transmitter on the pin is disabled.

Sorry. Here it comes:

root@AS-P-3-243610421:~# devmem2 0x11c07c w
/dev/mem opened.
Memory mapped at address 0xffffb8f8e000.
Read at address  0x0011C07C (0xffffb8f8e07c): 0x00020007

We have also tried setting it as 0x00050007 (PIN_INPUT in the dts). Output functionality for the STM32_NRST is still there but the problem I see persists. I guess Linux driver turns it into an output when needed.

Here is a scope illustration of that pin as we perform a normal reset (serial NOR boot). Here I have issued a reset about 15 times until the scope trigged on the negative pulse on the STM32_NRST line. Between resets the device is booting into U-Boot SPL then reset again.

What could possibly induce this kind of behavior on the pin? It is pulled up only by the internal pull-up on the STM32.

Mark L. said:

And to make sure I understand correctly, this is the sequence you're trying to accomplish?

1. TDA4 running
2. STM32 asserts a MCU_PORz
3. STM32 straps a boot mode
4. STM32 deasserts MCU_PORz
5. TDA4 asserts STM32_NRST (?)

Correct. The reason for us even having the possibility to reset the STM32 is to be able to upgrade its firmware.

Mark L. said:

If we confirm the MCU_PORz is happening, can you isolate the AF21 pin from the STM32 and report if the pin still drives low?

That is not possible for me since that line is hidden in the layers of the board.

One thing I come to think about is the timing between strapping and MCU_PORz. How sensitive is this? Perhaps we set boot strapping before we assert MCU_PORz.

In any case, there is a healthy amount of time between setting the strapping and deasserting the MCU_PORz.

Thank you for your assistance!

/Bo

Hi Mark,

Any news on this? On U-Boot 2024.04 it is very reproducible. From power-on it takes 15 resets to induce the hang.

Here is another screenshot of some of the signals. Please let me know if you need more info.

As you can see, the STM32 issues a reset by pulling the MCU_PORz low. Some 4 ms later the STM32_NRST line starts misbehaving and causes the device to die. To reproduce, I turn voltage off and on, and perform 15 resets.

In this next picture I have removed all connections (eth, debug, usb etc). It shows a more clean behaviour:

Regards,

/Bo

Hi Bo,

Bo Mellberg said:

We have also tried setting it as 0x00050007 (PIN_INPUT in the dts). Output functionality for the STM32_NRST is still there but the problem I see persists. I guess Linux driver turns it into an output when needed.

I think we're headed in the right direction. 0x00050007 enables the receiver buffer on the pin and sets the pin mux mode to GPIO. With this PADCONFIG setting, can we try controlling the GPIO (setting high and low)?

To do so, we write the following commands:

mw 0x600010 0xBFFFFFFF 1   /* This sets GPIO30 as output */
mw 0x600018 0x40000000 1     /* This sets GPIO30 to high */
mw 0x60001C 0x40000000 1    /* This clears GPIO30 to low */

I think confirming that we can control that pin as a GPIO will help us find a solution.

An alternative test to see if we can remove the driving low behavior is to disable the transmitter on the pin. This command should be

mw 0x11C07C 0x00250007 1

Hi Mark,

The problem with your solution is that we have not even reached the U-Boot prompt yet. I perform a reset as soon as I see the first debug console messages.

I suspect that there is something even earlier that is responsible for this behaviour. Are you sure that there are no watchdogs or boot counters active that supervises boot behaviour?

Zooming in on the MCU_PORz and STM32_NRST, we can see that the STM32_NRST is pulled low some 18 µs after MCU_PORz has been deasserted. Something is pulling this pin low very early in the boot up process. But only every 16th time:

Is there a "minimal uptime" that has to be reached before a reset is advisable?

I tried reverting back to older firmware:

SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')

but the problem persists.

Regards,

/Bo

Hi Mark,

Some more input.

I put an infinite loop in boot_init_f to be sure that the boot didn't proceed:

void board_init_f(ulong dummy)
{
#if defined(CONFIG_TARGET_J721E_A72_ASP3)
	volatile int loop_hang = 1;
	while (loop_hang != 2) {
		;
	}
#endif

Boot log:

U-Boot SPL 2024.04-ti-g4e5024c2fe73 (May 22 2025 - 09:00:58 +0000)
SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')
Trying to boot from SPI
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 10:34:56, Mar 25 2025
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Mon Mar 17 19:51:58 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 3.1 (firmware rev 0x000a '10.0.1--v10.00.01 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

This is as far as the boot gets now.

Even so, every 16th reset cycle I end up in the hanged state, with a low STM32_NRST.

Can the OP-TEE version play a role here?

/Bo

Hi again,

Sorry for the monologue, but I just want to let you know that I have been able
to reproduce the issue on the EVM platform.

Linux-ADAS SDK version 10.01.00.04. I created an SD card with the pre-built binaries and powered up the platform.

Pressing the MCU_PORz button 15 times gets the platform into a hanged state. MCU_PORz is no longer
responsive and the only way to get the EVM running again is toggling power.

It would be nice to hear if you can reproduce this behavior on your end. Also if you have any clues?

Regards,

/Bo

Hi Bo,

Thank you for sharing your findings.

I am able to reproduce this on my setup with SDK version 10.01.00.04 as well, using the pre-built binaries. Considering this is consistently reproducible after asserting MCU_PORz 15 times, I am inclined to think this may be controlled in software. Although, based on my findings, there should be no BOOTCOUNT enabled. Please let me consult with our software experts and investigate this further.

Regards,
Mark

Hi Mark,

Thank you for confirming. I thought I was going crazy for a while. I look forward to your findings.

/Bo

Hi Mark,

I have done some tests on previous version of the SDK:

SDK 10.01.00.04 - hangs
SDK 09.02.00.05 - hangs
SDK 08.06.01.02 - hangs

SDK 07.03.00.05 - works

Hope this helps,

/Bo

Hi Bo,

I'm finding that after 15 resets, the PMIC (TPS6594) is asserting the MCU_PORz (ie. nRSTOUT). Is that something you're observing as well? 

Hi Mark,

I will take a look at this on Monday. However, I find it strange that the issue is not seen on sdk7.

Regards,

/Bo

Hi Bo,

I have limited knowledge on the SDK and PMIC but I can see a scenario where the PMIC is being configured differently through I2C in the different SDK versions.

EDIT: I just found this thread that describes the 15-boot PMIC behavior: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1036120/tda4vm-does-the-pmic-chip-need-to-communicate-with-the-tda4vm-chip-before-the-pmic-works-properly

Regards,
Mark

Hi Mark,

That is a great find. Thank you!

According to this state diagram:

the recovery counter is only increased if there is a problem with the initial internal tests (BIST).

Could you hook us up with a PMIC expert to help us resolve this? Apparently our device (as well as the EVM board)
does not like the way it is booted, since the counter increases for each boot.

Best regards,

/Bo

I found this thread:

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1212682/tps6594-q1-how-to-configurate-tps6594-to-reset-tda4/4586109

where Michael Gambrill states that the counter will increase each warm-reset, and to avoid a lock-up the counter should be reset after a deliberate warm start.

We are fine with this solution but a confirmation from TI would be nice.

Regards,

/Bo

Hi Bo,

I will reach out to Michael for any implications with this solution.
Please let me get back to you by end of day tomorrow.

Regards,
Mark

Hello again,

Apologies for the delay--I'm awaiting a response. For the time being, can you move forward with this workaround to unblock any further development and I'll report back with any considerations with this workaround?

Regards,
Mark

I heard back from Michael.

This solution is fine. Software should clear the recovery after every warm reset. If there is a multi-PMIC solution, please clear the recovery counter of both PMICs.

Please let me know how this solution works out for you.

Hi Mark,

We do have a multi-PMIC setup. I have already checked the secondary PMIC counter and it does not increment so I think we are home safe with clearing only PMIC1 at the moment.

Thank you for your help, it is very much appreciated!

/Bo