[参考译文] AM2431：AM2431–RESETSTATz 保持低电平、在 MCU_OSC 引脚上未观察到时钟

你好、Manikandan V、

是的、RESETSTATz 置为无效依赖于系统时钟来完成内部复位序列。 请参阅数据表中的快照：

此致、

Stan

你好、Manikandan V、

关于不同复位输入对 AM243x RESETSTATz 输出信号行为的影响、您可能需要查看以下 E2E 常见问题解答：

定制电路板硬件设计：处理器复位输入复位状态输出和连接建议 

以下常见问题解答摘录包含有关 AM64x 和 AM243x SoC 的 RESETSTATz 输出行为的一些重要详细信息：

谢谢

此致、

Anastas Yordanov

你好、Manikandan

检查您是否能够分享原理图以进行快速检查并提供可能的建议。

电源架构 PMIC 是基于还是分立式？

时钟源晶体或振荡器。

此致、

Sreenivasa.

你好、Manikandan

此外、您能否验证 MCU_PORz 的转换。

慢速转换可能会干扰内部复位。

越快越好。

您能捕捉到波形吗？

此致、

Sreenivasa.

 

您好 Sreenivasa、

请查找附件 原理图 PDF 供参考。
请忽略 索引页、方框图和 GPIO 映射表 因为这些部分尚未更新以反映当前设计。

此设计使用 分立式电源架构（基于非 PMIC） 。
分频值、即 A 25MHz 晶体 使用：

• 器件型号： ABM10W –25.0000MHz 8-K1Z-T3

• 晶体规格： 25.0000MHz、8 pF、SMD

---

启动观察结果

在初始启动期间、我观察到了这一点 MCU_PORz 的发布时间早于预期 直至所需的所有电源轨都变为有效。

经过进一步的调查,我发现 内核电压监测器 IC 的行为未按预期运行 。 具体而言、监控器是 在 SENSE 电压变为有效之前不会将 RESET 引脚保持在低电平 。 相反、一旦上拉电源可用、RESET 信号就会变为高电平。 因此、复位时序和上电时序不符合预期。

请参阅随附的波形图、其中显示了 初始故障行为 、其中 MCU_PORz 被提前置为有效：

• 黄色：  VCC3V3_PREREG

• 绿色：  VCC_3V3_SYS

• 蓝色：  PORz

• 橙色：  VDD_CORE

---

用于复位验证的临时修改

为了获得有效的复位信号、我隔离了故障电压监控电路。
出于测试目的、我采购了 来自正常工作的 EVM 板的复位信号 并将其连接到 PORz 网络 （移除了 R171、并且将 EVM 复位信号注入 PORz 网络）。

经过此修改：

• MCU_PORz 现在变为高电平 VDD_CORE 电源轨变为有效后

• RESET 大约释放 内核电源达到其标称电平后 10ms

请参阅随附的波形图、其中显示了 更正了行为 。

• 黄色：  VCC3V3_PREREG

• 绿色：  VCC_3V3_SYS

• 蓝色：  PORz

• 橙色：  VDD_CORE

---

其他注意事项

1. VDD_CORE 电压 电流测量值 0.83V ,而不是 0.85 V .
   VDD_CORE 稳压器反馈电阻 R118 特意针对 0.83V 电压设计。这是由于电阻器采购问题；当前原理图版本显示了不正确的反馈配置 (0.75V)、将在下一个版本中进行更正。

2. 。 来自 EVM 的复位信号 仅用于验证。
   。 5V 主输入 在该测试期间、还通过同一 EVM 板提供定制电路板。

---

即使在实施上述修改后、也不会在中观察到任何变化 RESETSTATz 和 MCU_RESETSTATz 要容易得多。 两个信号都继续保持在中 驱动至低电平 状态。

如果您需要、请告诉我 所有电源轨的完整上电序列波形 或任何其他测量。

谢谢。此致、
马尼坎丹五世

e2e.ti.com/.../PROC_5F00_REVB_5F00_02_2D00_02_2D00_2026.pdf

你好  Manikandan

谢谢你。

您能否探测 VDD_CORE、时钟和 MCU_PORz

MCU_PORz 应在 VDD_CORE 斜升后延迟 9.5ms 分钟、并仅在时钟稳定后释放。

此致、

Sreenivasa.

您好 Sreenivasa、  

感谢您的回答、  

请找到以下波形 VDD 内核 — Ch1、MCU_PORz - CH2，时钟 — Ch3

VDD 内核--> MCU_PORz --> 12.11ms 延迟  

没有时钟活动-->在 R138 电阻器中探测  

注意：请查看原理图上的复位信号部分、我删除了我们在应用中不需要的几个电源部分（例如：以太网和测试接头电源） 仅供参考。  

谢谢、  

马尼坎丹五世  

你好、 Manikandan  

R140 0r 似乎已填充。

仅在使用振荡器时、才需要这样做。

您是否可以 DNI 并进行检查。

请使用高 Z 示波器探头进行探测。

此致、

Sreenivasa.

您好 Sreenivasa、

感谢您的支持。

卸下后 R140 、 时钟现在已正确生成 。 我能够观察到这两者 RESETSTATz 和 MCU_RESETSTATz 器件 高电平 状态。 我也做了一个 JTAG 连接测试 、它的工作没有任何问题。

感谢您和本主题中的其他人提供的指导和帮助。

请找到随附的波形/图像以供您参考。

此外、您可以查看我的 DDR、eMMC、OSPI 和 USB 接口电路 及其相关的复位电路。 这将有助于完成后续启动阶段。

谢谢。此致、
马尼坎丹五世

你好、Manikandan

感谢您更新进度、并很高兴看到问题已解决。

您可以查看我的 DDR、eMMC、OSPI 和 USB 接口电路 及其相关的复位电路。 这将有助于启动的后续阶段。

如果您正在与任何 TI 销售或 TI 支持成员合作、您可以更新吗？

此致、

Sreenivasa.

你好、Manikandan

如果您没有与任何 TI 现场团队合作、请为此 E2E 中的每个外设提交单独的 E2E、并添加任何问题或重点审查点以供专家提供支持。

添加线程后、请将链接添加到此线程。

此致、

Sreenivasa.

您好 Sreenivasa、

我懂了。 我将为每个外设创建单独的 E2E 主题、并包含具体问题或关注领域以供审核。 创建线程后、我将向该线程添加相应的链接。

此致、
马尼坎丹五世

你好、Manikandan

感谢您的参与。

如果您目前不在与任何 TI 销售或支持部门合作、我建议您联系他们。

如果您能够确认自己未在 ANT TI 字段中工作、我可以与 TI FIED 团队联系以了解该流程。

此致、

Sreenivasa.

您好 Sreenivasa、

感谢您发送邮件。

目前、我不在任何 TI 销售或支持现场团队工作。 您能否咨询 TI 现场团队了解该流程并就后续步骤提供建议？

此致、
马尼坎丹五世

你好、Manikandan

谢谢、我将与销售团队核实并更新您。

此致、

Sreenivasa.

您好 Sreenivasa、

关于当前来自 EVM 板的复位信号、我们目前依赖于的 EVM  用于 MCU_PORz 的基于 VDD_CORE 检测的复位信号 。 我们的目标是消除对 EVM 板的这种依赖。

如果有、请告知我们  备用引脚、状态信号或推荐方法  可用于生成或鉴定  MCU_PORz  时序控制信号？ 如果有任何内部状态或外部信号可用于满足复位延迟要求、相关指南将会有所帮助。

请建议采取合适的方法来解决此问题。

此致、
马尼坎丹五世

你好、Manikandan

谢谢你。

我将 MCU_PORz 拆 分为了一个单独的线程以进行后续处理

(9) 关于：AM2431：AM2431–MCU_PORz 生成 — 处理器论坛-处理器 — TI E2E 支持论坛

我将在另一个主题中添加我的评论

此致、

Sreenivasa.

您好 Sreenivasa、

感谢您提供的信息。 我将与相关团队协调、按照建议进行联系。

谢谢。此致、
马尼坎丹五世

您好 Sreenivasa、

我已向您共享的邮件 ID 发送了一封电子邮件。 然而、我们尚未收到任何答复。 您能否告诉我们、如果我们方面缺少任何内容、或者获得现场支持有任何限制或条件？

谢谢、
马尼坎丹五世

你好、Manikandan

感谢您发送编修。

我假设您已包含销售团队的应用程序和其他信息。

请留出几天时间让他们回复。

此致、

Sreenivasa.

您好 Sreenivasa、

感谢您的更新。 我相信我们已经与销售团队分享了必要的信息；让我们再等几天、等待他们的答复。

与此同时、我们正面临另一个与有关的问题 OSPI 引导 我们的 AM2431 定制板上。 具体而言、 OSPI 闪存擦除操作成功 、但是 刷写映像失败 、并且我们在 OSPI 引导期间始终遇到闪存错误。

问题摘要：

• SBL 空 (HS-SBL FS) 通过 UART 成功启动、SYSFW/内核初始化完成。

• 正确检测到 OSPI 闪存（JEDEC ID 和 SFDP 读取正常）。

• OSPI 闪存 IO 和写入/读取测试通过。

• 块擦除操作失败 、由 OSPI 闪存诊断程序报告。

• 在 UART Uniflash 期间、闪存擦除可能会开始、但 刷写 SBL 映像失败 。

• 切换到 OSPI 引导时、不会观察到 UART 日志。

• OSPI 波形显示了擦除命令期间的 CLK/CS/DQ 活动、但 擦除后无进一步的总线活动 。

总体而言、可以使用 OSPI 读取/写入访问、但 擦除/闪存操作未成功完成 它阻止了 OSPI 引导。

此外、我们还有一个活动模块 TI E2E 论坛主题 该问题的答案。 我正在分享论坛链接以供您参考。 如果您注意到与您的经验有任何相似之处或之前遇到过相关问题、您的意见对我们非常有帮助。

 回复：AM2431：AM2431–FS 定制板上使用 HS-SBL 时 UART Uniflash 刷写故障 

如果您遇到类似问题、或者对如何继续有任何指导、请告知我们。

谢谢。此致、
马尼坎丹五世

你好、Manikandan、  

谢谢你。

[引述 userid=“177086" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1601824/am2431-am2431-resetstatz-remains-low-no-clock-observed-on-mcu_osc-pins/6174593

如果您没有与任何 TI 现场团队合作、请为此 E2E 中的每个外设提交单独的 E2E、并添加任何问题或重点审查点以供专家提供支持。

添加线程后、请将链接添加到此线程。

[/报价]

不确定您是否有机会启动单独的线程。

如果您可以添加 E2E 请求以供 OSPI 部分审查、我可以添加一些发现、需要更改下拉电阻值并填充上拉电阻。

此致、

Sreenivasa.

你好、Manikandan、

谢谢你。

我看到 Vaibhav 支持线程,应该没问题。

[报价 userid=“658703" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1601824/am2431-am2431-resetstatz-remains-low-no-clock-observed-on-mcu_osc-pins/6189655

此外、我们还有一个活动模块 TI E2E 论坛主题 该问题的答案。 我正在分享论坛链接以供您参考。 如果您注意到与您的经验有任何相似之处或之前遇到过相关问题、您的意见对我们非常有帮助。

 回复：AM2431：AM2431–FS 定制板上使用 HS-SBL 时 UART Uniflash 刷写故障 

如果您遇到类似问题、或者对如何继续有任何指导、请告知我们。

[/报价]

此致、

Sreenivasa.

如果您可以添加 E2E 请求以供 OSPI 部分审查、我可以添加一些发现、需要更改下拉电阻值并填充上拉电阻。

您好 Sreenivasa、

感谢您的澄清和指导。

我懂了。 由于 Vaibhav 已在支持当前的 E2E 主题、因此我们将继续与他合作解决这个问题。 正如建议的那样、我们还将考虑提出 A 单独的 E2E 申请进行 OSPI 部分审查 并在创建后在现有线程中共享链接。

在此期间、如果有任何问题、请告知我们 与组装或取消组装 OSPI 部分中的元件相关的问题 。 您之前提到过、可能有一些与相关的发现 下拉值和所需的上拉电阻 缓冲器选项。 如果您能分享这些意见或建议、我们将非常有帮助、能够迅速解决这些问题并朝着解决问题的方向前进。

Vaibhav 目前正在论坛上为我们提供支持、如果可能、您的其他意见或想法将极大地帮助我们加快解决此问题的速度。

再次感谢您的支持。

此致、
马尼坎丹五世

你好、Manikandan、

请进行以下更改并快速检查。

请组装 D0//D7 上拉

将 OSPI_CLK 下拉电阻降至 10K

此致、

Sreenivasa.

您好 Sreenivasa、

在您的指导下、我们进行了以下硬件更改并执行了快速验证：

• OSPI CLK 下拉电阻器更改为 10kΩ

• OSPI 数据线 已组装 DQ0 至 DQ7 上拉电阻 (10kΩ)

但是、即使进行了这些更改、也可以使用 仍然存在相同的闪烁问题 。

为了供您参考、请找到在上述修改后捕获的 UART Uniflash 调试日志：

~/ti/mcu_plus_sdk_am243x_11_01_00_17/tools/boot $ python3 uart_uniflash.py -p /dev/ttyUSB0 --cfg=sbl_userbuilt/userbuilt_sbl_null.cfg

Parsing config file ...
Parsing config file ... SUCCESS. Found 3 command(s) !!!

Executing command 1 of 3 ...
Found flash writer ... sending sbl_userbuilt/sbl_uart_uniflash.Release.hs_fs.tiimage

Sent flashwriter sbl_userbuilt/sbl_uart_uniflash.Release.hs_fs.tiimage of size 322941 bytes in 29.17s.

Executing command 2 of 3 ...
Command arguments : --operation=erase --flash-offset=0x0 --erase-size=0x100000
Sent flash erase command.
[STATUS] SUCCESS !!!

Executing command 3 of 3 ...
Command arguments : --file=sbl_userbuilt/sbl_null.Release.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sent sbl_userbuilt/sbl_null.Release.hs_fs.tiimage of size 282997 bytes in 28.06s.
[STATUS] ERROR: Flashing failed !!!

All commands from config file are executed !!!

请查看上述内容、并告知我们是否建议您进行其他硬件检查或 OSPI 配置更新。

如果您具有 AM2431 的任何已知可正常工作的 OSPI 引导二进制文件或参考文件 请您与我们分享一下吗？
我们希望从最后测试相同内容、以排除任何与配置相关的问题。

我们目前对是否有一些有疑问 AM2432 至 AM2431 转换期间的配置更改 或任何 安全相关选项 、可能是导致此行为的原因。

 

此致、
马尼坎丹五世

你好、Manikandan  

谢谢你。

请保留硬件更改 — 建议这样做。

请与 Vaibhav 合作、进一步调试您所面临的问题。

此致、

Sreenivasa.