[参考译文] DRA829V：MCU_PORz 复位时的焊球状态

有人吗？

尊敬的 Bo：

我在我们的一个 EVM 上探测了此引脚、即使在将 MCU PORz 置为有效后、它也会保持悬空。 即使使用了上拉电阻器、我也没有观察到引脚驱动为低电平。

您能在看到此问题时澄清一下吗？

a.执行冷启动(对电路板进行下电上电)时会出现此问题
b.在 SoC 已运行后将 MCU PORz 置为有效时会发生此问题

此外、您能否确认是否 遵循了数据表中指定的 SoC 上电序列？

您是否在所有电路板上都看到了这种行为？

谢谢。此致、
标记

您好、Mark、

a.编号 挂起时、对器件进行下电上电可恢复。 我们尝试使用 PMIC 来切换电源、但这会带来其他问题。 我们确实需要了解如何执行正确的 MCU_PORz 来正确复位 SoC。

B.是的、正确。

我将检查用于控制复位过程的 STM32的状态机。

我在我尝试过的所有电路板上都看到了这种情况、5-10个、同时努力使 U-Boot 2024.04正常工作。

此致、

/BO

尊敬的 Bo：

您能否 在将 MCU_PORz 置为有效之前和之后提供 PADCONFIG31 (0x00011C07C)寄存器值？

此致、
标记

您好：Mark、

寄存器读出：

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

显然、当器件处于挂起状态时、我无法读取它。

上电序列正常。 关闭电源后、引导始终正常工作。 对于复位序列、我们将 MCU_PORz 置为有效、配置所需的引导模式(DFU 或 SPI NOR)、在100ms 后、我们将 MCU_PORz 置为无效、从而使器件退出复位。

此致、

/BO

尊敬的 Bo：

已了解挂机时无法读取设备。 感谢您检查上电序列。

您能否使用 md.l 报告整个32位寄存器值？ 我对第21位(TXDISABLE)感兴趣。 我假设在您的软件中此位设置为0以驱动 STM32_NRST。 器件复位(包括 MCU_PORz)时、该位设置为1、并禁用引脚上的发送器。

为了确保我正确理解、这是您尝试完成的顺序？

1. TDA4运行
2. STM32将 MCU_PORz 置为有效
3. STM32搭接引导模式
4. STM32将 MCU_PORz 置为无效
5. TDA4将 STM32_NRST (？)置为有效

TDA4应在哪个步骤将 AF21引脚驱动为低电平并在 STM32上将复位置为有效？ 我想象在第4步之后、无法执行第2-4步。 如果 TDA4 SoC 在步骤2之前将 STRM32_NRST 置为有效、则我看不到正在如何执行 MCU_PORz (假设它们控制着彼此的复位线路)。

如果我们确认 MCU_PORz 已发生、您能否将 AF21引脚与 STM32隔离并报告该引脚是否仍驱动为低电平？

您好：Mark、

Unknown 说：

您能否使用 md.l 报告整个32位寄存器值？ 我对第21位(TXDISABLE)感兴趣。 我假设在您的软件中此位设置为0以驱动 STM32_NRST。 器件复位(包括 MCU_PORz)时、该位设置为1且引脚上的发送器被禁用。[/报价]

抱歉。 来看看：

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

我们还尝试了将其设置为0x00050007 (DTS 中的 PIN_INPUT)。 STM32_NRST 的输出功能仍然存在、但我看到的问题仍然存在。 我想 Linux 驱动程序会在需要时将其转换为输出。

下面是我们执行正常复位(串行 NOR 引导)时该引脚的示波器图示。 在这里、我发出了大约15次复位、直到示波器在 STM32_NRST 线路上的负脉冲触发为止。 在复位之间、器件会引导至 U-Boot SPL、然后再次复位。

什么可能会导致引脚上出现这种行为？ 它仅由 STM32上的内部上拉电阻器上拉。

Unknown 说：

为了确保我正确理解、这是您尝试完成的顺序？

1. TDA4运行
2. STM32将 MCU_PORz 置为有效
3. STM32搭接引导模式
4. STM32将 MCU_PORz 置为无效
5. TDA4将 STM32_NRST (？)置为有效

[/报价]

没错。 我们甚至可以重置 STM32的原因是能够升级其固件。

Unknown 说：

如果我们确认 MCU_PORz 正在发生、您能否将 AF21引脚与 STM32隔离并报告该引脚是否仍驱动为低电平？

[/quote]

这对我来说是不可能的,因为这条线隐藏在板层中。

我想到的一点是 Strap 配置和 MCU_PORz 之间的时序。 它有多敏感？ 我们可能会在将 MCU_PORz 置为有效之前设置自举。

在任何情况下、设置搭接和将 MCU_PORz 置为无效之间都存在一段正常的时间。

感谢您的帮助！

/BO

[/quote][/quote]

您好：Mark、

有什么关于这方面的消息吗？ 在 U-Boot 2024.04上、它可以很好地重现。 在上电时、需要15次复位来引起挂起。

这是一些信号的另一个屏幕截图。 如果您需要更多信息、请告诉我。

如您所见、STM32通过将 MCU_PORz 拉至低电平来发出复位。  大约4ms 后、STM32_NRST 线路开始出现错误行为并导致器件裸片。 为了重现故障、我关闭和打开电压、然后执行15次复位。

在下一张图片中、我已移除所有连接(eth、Debug、USB 等)。 它显示了一种更干净的行为：

此致、

/BO

尊敬的 Bo：

Unknown 说：

我们还尝试了将其设置为0x00050007 (DTS 中的 PIN_INPUT)。 STM32_NRST 的输出功能仍然存在、但我看到的问题仍然存在。 我想 Linux 驱动程序会在需要时将其转换为输出。

我想我们正朝着正确的方向前进。 0x00050007启用引脚上的接收器缓冲器、并将引脚多路复用模式设置为 GPIO。 使用此 PADCONFIG 设置、我们能否尝试控制 GPIO (设置为高电平和低电平)？

为此、我们编写以下命令：

MW 0x600010 0xBFFFFFFF 1  /*这会将 GPIO30设置为输出*/
mW 0x600018 0x40000000 1   /*这会将 GPIO30设置为高电平*/
mw 0x60001C 0x40000000 1  /*这会将 GPIO30清除为低电平*/

我认为、确认我们可以作为 GPIO 控制该引脚将有助于找到解决方案。

要查看我们是否可以消除驱动低电平行为、另一项测试是禁用引脚上的发送器。 此命令应为

MW 0x11C07C 0x00250007 1.

您好：Mark、

您的解决方案存在问题、我们甚至还没有到达 U-Boot 提示符。 看到第一条调试控制台消息后就会执行复位。

我怀疑,甚至更早的事情是这种行为的责任。 是否确定没有监视引导行为的看门狗或引导计数器处于活动状态？

通过放大 MCU_PORz 和 STM32_NRST、我们可以看到 STM32_NRST 18 µs 在 MCU_PORz 被置为无效后被拉至低电平。 在启动过程的早期将该引脚拉低。 但仅每16次：

在建议进行重置之前、是否必须达到"最短正常运行时间"？

我尝试恢复到较旧的固件：

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

但问题仍然存在。

此致、

/BO

您好：Mark、

一些输入。

我在 boot_init_f 中放置了一个无限循环、确保引导不会继续：

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

引导日志：

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 optee.readthedocs.io/.../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

这是从现在开始就可以了。

即便如此、每第16个复位周期 I 最终会处于挂起状态、具有低 STM32_NRST。

OP-TEE 版本能否在这里发挥作用？

/BO

再次大家好、

我只是想让你知道,我已经和你在一起了。
在 EVM 平台上重现问题的方法。

Linux-ADAS SDK 版本10.01.00.04。 我创建了一个带有预构建二进制文件的 SD 卡并为平台通电。

按下 MCU_PORz 按钮15次会使平台进入挂起状态。 MCU_PORz 不再是
响应迅速、使 EVM 再次运行的唯一方法是切换电源。

如果你能在你的最后重现这种行为,那将是很好的 如果你有任何线索?

此致、

/BO

尊敬的 Bo：

感谢您分享调查结果。

我也可以使用预构建的二进制文件在使用 SDK 版本10.01.00.04的设置中重现此问题。 考虑到这在将 MCU_PORz 置为15次后始终可重现、我倾向于认为这可在软件中控制。 尽管、根据我的调查结果、应该不会启用 BOOTCOUNT。 请让我咨询我们的软件专家、并对此进行进一步调查。

此致、
标记

您好：Mark、

感谢您的确认。 我以为我会疯了一段时间。 我期待您的发现。

/BO

您好：Mark、

我对之前版本的 SDK 进行了一些测试：

SDK 10.01.00.04 -挂起
SDK 09.02.00.05 -挂起
SDK 08.06.01.02 -挂起

SDK 07.03.00.05 -正常工作

希望这对您有所帮助、

/BO

尊敬的 Bo：

我发现15次复位后、PMIC (TPS6594)会将 MCU_PORz (即 nRSTOUT)置为有效。 这也是您观察到的吗？  

您好：Mark、

我将在星期一查看这一点。 但是我觉得奇怪的是,这个问题没有在 sdk7上看到。

此致、

/BO

尊敬的 Bo：

我对 SDK 和 PMIC 的了解有限、但我可以看到一种情况、在不同的 SDK 版本中通过 I2C 以不同的方式配置 PMIC。

编辑：我刚刚找到了这个描述15引导 PMIC 行为的主题： 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

此致、
标记

您好：Mark、

这是一个伟大的发现。 谢谢！

根据此状态图：

仅当初始内部测试(BIST)出现问题时、恢复计数器才会增加。

您能联系我们的 PMIC 专家来帮助我们解决这个问题吗？ 显然是我们的器件(以及 EVM 板)
不喜欢它的引导方式、因为每次引导时计数器都会增加。

此致、

/BO

我找到了此主题：

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

 迈克尔 ·甘布里尔表示计数器将增加每次热复位、并且为了避免锁定、应在有意的热启动后重置计数器。

我们对该解决方案很满意、但最好得到 TI 的确认。

此致、

/BO

再次大家好：

对延迟表示歉意——我正在等待回应。 目前、您能否继续使用此变通办法来阻止任何进一步的开发、我将报告有关此变通办法的任何注意事项？

此致、
标记

我从 Michael 那里听到了。

这个解决方案很好。 软件应在每次热复位后清除恢复。 如果有多 PMIC 解决方案、请清除两个 PMIC 的恢复计数器。

请告诉我这款解决方案是如何为您解决的。

您好：Mark、

我们有一个多 PMIC 设置。 我已经检查了次级 PMIC 计数器、它没有递增、因此我认为我们目前只清除 PMIC1、可以保证家庭安全。

感谢您的帮助、非常感谢！

/BO