Other Parts Discussed in Thread: SYSCONFIG
器件型号: TDA4VEN-Q1
您好、
在 TDA4VEN 上开发 C7x 期间、我们遇到了一个间歇性问题、即 C7x 内核无法启动。 故障排除后、我们发现 当启动失败时、程序卡在 DPL_init () 函数内的 SOC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2) 处。 我们想知道根本原因和相应的解决方案。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Other Parts Discussed in Thread: SYSCONFIG
器件型号: TDA4VEN-Q1
您好、
在 TDA4VEN 上开发 C7x 期间、我们遇到了一个间歇性问题、即 C7x 内核无法启动。 故障排除后、我们发现 当启动失败时、程序卡在 DPL_init () 函数内的 SOC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2) 处。 我们想知道根本原因和相应的解决方案。
您好、Qiang Leo、
您能否查看此主题、该主题具有类似的故障:
e2echina.ti.com/.../tda4ven-q1-tda4ven-q1-j722s-c7x-may-get-stuck-writing-mrr-registers-during-ipc-initialization
疑难解答后、我们发现 当启动失败时、程序在 DPL_init () 函数内的 SOC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2) 处卡住了。
SOC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2) 处的挂起可能是软件启动顺序竞态条件。 当 Linux (A53) 启动 remoteproc/rpmsg 时、它会在 C7x 邮箱 FIFO 完成 DPL_init 之前向 C7x 邮箱 FIFO 发送一条 IPC 消息。 由于 C7x 邮箱中断通过 CLEC 进行电平触发、因此挂起的消息会使中断线路持续置为有效、尚未注册 ISR、从而导致 C7x 在首次进行片外总线访问时挂起。
您能否请尝试耗尽所有待处理的邮箱 FIFO (MAILBOX_MESSAGE)、直到 MAILBOX_MSGSTATUS 为零 、并清除 MAILBOX_IRQSTATUS_CLR、然后再继续处理 C7x 端的 DPL_INIT。
在 Linux 方面、确保在 C7x 固件发布其 RPMSG_NS_CREATE 通知而不仅仅是在 RPROC_RUNNING 上之前、不会向 C7x 发送 rpmsg 消息。
您是否还能确认您的 Processor SDK RTOS 和 MCU+ SDK 版本、以及在 C7x 启动之前 Linux Remoteproc 是否处于运行状态?
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
感谢您的答复。 在执行 DPL_init 函数之前、我按照您的说明检查了邮箱状态。 代码如下所示、但冻结问题仍未解决。 我是错误地编写了代码、还是需要与 ARM 端一起修改?如果需要修改 ARM 端代码、我应该如何在此处进行更改?

我使用的 SDK RTOS 版本为 10.0.0.05、MCU SDK 版本为 10.0.0.25。
您好、Qiang Leo、
在执行 DPL_init 函数之前、我按照您的指示检查了邮箱状态。
您能否确认 IpcNotify_clearMailboxFifo_cls() 被调用的确切位置? 是否可以在输入 DPL_init () 之前尝试将其作为 main() 中的第一项运行。
您是否也可以尝试使用 IpcNotify_mailboxDisableInt () 基元(在 source/drivers/ipc_notify/V0/ipc_notify_V0_mailbox.h 中定义)来屏蔽邮箱中断、以便在排水期间到达的新消息不能重新使中断线路生效。
此致、
Shabary S Sundar
您好、Qiang Leo、
此问题是否实际上不是由中断本身引起的?
在 DPL_init () 中的 SOC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2) 之前、请尝试添加对 JTAGID 寄存器的读取(相同的 MAIN_CTRL_MMR0 块,无需解锁):
Volatile uint32_t jtagId =*(volatile uint32_t *) 0x00100014U;
(void)jtagId;
SoC_controlModuleUnlockMMR (SOC_DOMAIN_ID_MAIN、2);
如果 C7x 在进行该读取时挂起、则问题不是邮箱中断—它指向防火墙或 PSC 问题(开始运行时,C7x 启动程序尚未访问 MAIN_CTRL_MMR0)。
如果读取成功、但脚踢写入仍发生挂起、它会确认问题出在解锁路径或中断路径中。
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
我错误地点击了“这解决了我的问题“。 此问题 未 解决。 您能否继续提供帮助?
您好、Qiang Leo、
这是由您之前提到的防火墙或 PSC 问题引起的吗?
您能否确认在 Linux 启动后、C7x 是由 R5F 上的 SBL 或 A53 上的 Linux Remoteproc 从复位状态释放 C7x? 如果涉及 Linux、请将 UART 引导日志与挂起一起共享。
都会发生这种现象发现 C7x 内核在读取 JTAG ID 寄存器时挂起、 每次
您是否也可以尝试在 DPL_init () 开始时在 JTAGID 读取之前添加 CPU busy-wait。
易失性 uint32_t i;
对于 (i = 0;i < 100000000U;i++){
__ASM____Volatile__(“nop“);
}
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
是否还能在 DPL_init () 的最开始处、在 JTAGID 读取之前、尝试添加 CPU busy-wait。
每次启动时它仍然挂起。也许不应访问 JTAGID 寄存器。
您能否确认 C7x 是在 Linux 启动后由 R5F 上的 SBL 还是通过 A53 上的 Linux Remoteproc 释放 C7x? 如果涉及 Linux、请共享挂起时的 UART 引导日志。
C7x 内核由 R5F SBL 从复位状态释放。
您好、Qiang Leo、
您能否请暂时删除 JTAGID 读取并 仅保留 在原始 SOC_controlModuleUnlockMMR() 调用之前的 CPU 延迟。
R5F SBL 将 C7x 内核从复位状态释放。
您是否还能确认是否对 SBL 引导流程进行了任何更改? 您是使用 MCU+ SDK 10.0.0.25 中的库存 SBL 还是 定制的 ?
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
您能否暂时删除 JTAGID 并 仅保留 原始SOC_controlModuleUnlockMMR()调用之前的 CPU 延迟。 [/报价]我 暂时删除 JTAGID 读取、并 仅保留 原始
SOC_controlModuleUnlockMMR()调用之前的 CPU 延迟时间。
这肯定会导致程序每次卡在 SOC_controlModuleUnlockMMR () 处。
您是否还能确认您是否对 SBL 引导流程进行了任何更改? 您使用的是 MCU+ SDK 10.0.0.25 中的库存 SBL 还是 定制的 ?也许我之前没有说明自己。 实际上、DSP 固件在 U-Boot 引导阶段由 U-Boot 加载。 此 U-Boot 是根据官方原始源代码编译的、无需进行任何修改。 以下是 Linux 引导日志。 我们已移除 R5 固件、因此 R5 内核保持非活动状态。 尽管日志表明 C7x 已连接、但实际上 C7x 内核无法正常启动。
[/quote]
您好、Qiang Leo、
应找出原因的几个要点和一个测试。
在 dmesg 上: 78000000.r5f 是 运行 DM 的 WKUP R5F、由 U-Boot SPL 通过加载 — 这是预期的和必需的,而不是用户 tispl.bin R5F。 您的 MCU R5F0x79000000() 和主 R5F ()0x78400000正确处于非活动状态。 因此 DM 处于活动状态并且 TISCI 正在运行。
当挂起地址时: 0x00100014 在 MAIN_CTRL_MMR0 内部、而不是 JTAGID 内部。 J722S 的实际 JTAGID 位于 0x43000014 (WKUP_CTRL_MMR0)。 SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2) 在中写入 KICK0 0x00109008。
在 100M NOP 上使其 100%可重现 的延迟:故障恶化表示系统中的另一个代理(很可能是 Linux Remoteproc 连接)在窗口期间状态改变—关闭 C7x 对 MAIN_CTRL_MMR0 的访问。 由于您从 U-Boot(不是 WKUP R5F SBL)引导 C7x、因此可能不会执行 SBL 通常不会执行的完整防火墙/时钟设置。
您能否运行此测试:
0x43000014 —真实 JTAGID(WKUP 域)0x00100000 —MAIN_CTRL_MMR0 的开始此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
我遇到了一个问题、无法使用 CCS 中的 Memory Browser 读取存储器、因此我改为使用 devmem2 命令。
1.我 md devmem2 分别使用 U-Boot 中的命令和 Linux 中的命令检查了这两个地址处的值。 地址处的值 0x00100000 为 0x61800215、地址处的值 0x43000014 为 0x0bba002f。 无论 C7x 是否暂停、这两个地址的值都保持不变。
2.在 C7x 引导过程中、我将地址中的值写入 0x00100000 0x43000014 共享存储器。 我观察到 C7x 偶尔会卡在它从地址读取值的阶段 0x00100000。 结合解锁 MMR 寄存器的已知问题、我想知道 C7x 进入暂停状态时是否会丢失对 MMR 寄存器区域的读取/写入权限。

此致、
Qiang Leo
您好、Qiang Leo、
要确认这是否是防火墙问题、请按照以下步骤收集 TIFS 跟踪日志。
第 1 步 — 在电路板配置中启用 TIFS 跟踪
在 U-Boot 源代码树中,编辑 board/ti/j722s/board-cfg.yaml:
- trace_dst_enables: 0x00
- trace_src_enables: 0x00
+ trace_dst_enables: 0x0D
+ trace_src_enables: 0x3F
trace_dst_enables: 0x0D 启用 UART + ITM (JTAG)+存储器缓冲器输出。 trace_src_enables: 0x3F 启用包括安全/防火墙操作在内的所有跟踪源。
注意: 启用跟踪会对性能产生影响。 仅用于调试。
步骤 2—重建 U-Boot 和闪存
# From your U-Boot build directory
make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- j722s_evm_a53_defconfig
make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu-
将生成的复制 tispl.bin 到 SD 卡引导分区、替换现有分区:
cp tispl.bin /media/<your-sd-card>/boot/
sync
跟踪配置在 tispl.bin TISCI_MSG_BOARD_CONFIG SPL 早期烘焙到 TIFS 并发送到 TIFS—无法在运行时启用它、需要重新构建。
步骤 3—重现挂起
正常启动电路板。 让 Linux 完整启动、并让 Remoteproc 加载并连接 C7x 固件。
重要说明: 挂起后 、请勿对电路板进行下电上电。 TIFS 跟踪缓冲器位于片上 SRAM 中、会在断电或复位时丢失。 使电路板保持挂起状态、并立即继续执行步骤 4。
第 4 步 — 连接 CCS 并转储跟踪缓冲区
当 JTAG/CCS 处于挂起状态时将其连接至电路板。
在 CCS 内存浏览器中:
0x4405F0000x1000 (4096 字节).bin 或 .hex 文件或者、使用 CCS Scripting Console:
mem.savebin("tifs_trace.bin", 0x4405F000, 0x1000);
J722S TIFS 跟踪缓冲区: base =
0x4405F000、size =0x1000字节(根据 TI TISCI 文档)。
步骤 5—同时捕获连接前后的 devmem2 读数
在它处、从 A53 终端、请从两点捕获以下内容:
在 Linux Remoteproc 连接 C7x(引导早期)之前:
devmem2 0x00100000 w # MAIN_CTRL_MMR0 PID — confirms A53 access
devmem2 0x43000014 w # WKUP_CTRL_MMR0 JTAGID — confirms WKUP access
C7x 挂起后(A53 仍处于活动状态):
devmem2 0x00100000 w # If this still reads OK from A53, confirms only C7x is blocked
该交叉检查确认防火墙有选择地阻止 C7x 主器件 ID、而不是 A53。
步骤 6—分享以下结果:
tifs_trace.bin 转储来源 0x4405F000devmem2 步骤 5 的输出dmesg 显示 Remoteproc 连接序列的完整输出 TISCI_MSG_SET_FWL_REGION 0x90000x00100000–0x00107FFF在 Linux Remoteproc 连接期间发出的、针对 MAIN_CTRL_MMR0 防火墙区域 () 的任何(消息 ID)调用、在权限列表中不包括 C7x 主 ID (privId 32/33)。 这将确认 Linux 在 C7x 固件启动后动态缩小 MAIN_CTRL_MMR0 防火墙、导致 C7x 尝试访问内的该区域时静默挂起 SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2)。
请分享输出并进行进一步分析。
您也可以参阅以下 tisci 文档: https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html#trace-memory-buffer-location
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
tifs_trace.bin转储来自
0x4405F000
在重新生成 C7x 挂起问题后、我 通过 CCS 读取地址 0x4405F000 处的值、并将数据保存到 tifs_trace.bin中。 结果表明此文件中的所有内容均为零。
的输出devmem2步骤 5
devmem2 在 Linux 启动后使用命令读取地址 0x00100000 和 0x43000014 的值。您的完整dmesg输出显示 Remoteproc 连接序列
此致、
Qiang Leo
您好 、Qiang Leo、
重新生成 C7x 挂起问题后、我 通过 CCS 读取地址 0x4405F000 处的值并将数据保存到tifs_trace.bin。 结果表明此文件中的所有内容均为零。
您能否确认修改后的 board-cfg.yaml 代码是重建到内部新的签名 boardcfg blob 中 tispl.bin (还是刷写了重建的二进制文件)?
为了获得有效的跟踪、make mrproper 需要对 U-Boot 进行完全清理重建(然后是完整编译)、以便将新的 YAML 重新生成到签名的 blob 中。
但是、此方法无法重现 C7x 挂起问题。 我怀疑暂停 U-Boot 倒计时会改变引导时序、从而使 C7x 固件能够正常加载。
C7x 固件需要写入一个寄存器 ( TIMER1_CLKSEL AT 0x001081B4 ) 以设置其操作系统节拍计时器源。 该寄存器位于防火墙保护区域 (MAIN_CTRL_MMR0 分区 2) 内。
我们可以将这个单个寄存器写入从 C7x 移动到 U-Boot 吗。 U-Boot 在 A53 上运行、后者始终可以完全访问 MAIN_CTRL_MMR0。 在 C7x 开始之前配置计时器多路复用器。
board_late_init() 在中添加 board/ti/j722s/evm.c (TISCI 打开后运行,之前运行) rproc start c7x:
/* Pre-configure TIMER1_CLKSEL for C7x */
writel(0x68EF3490, 0x00109008); /* MMR0 partition 2 KICK0 unlock */
writel(0xD172BC5A, 0x0010900C); /* MMR0 partition 2 KICK1 unlock */
writel(0x0, 0x001081B4); /* TIMER1_CLKSEL = HFOSC0_CLKOUT */
writel(0x0, 0x00109008); /* re-lock partition 2 */
writel(0x0, 0x0010900C);
这将在 C7x 运行之前从 A53(具有防火墙访问权限)写入计时器多路复用器。
在 SysConfig ti_dpl_config.c 为 C7x 内核生成的中、删除现在冗余的写入 Dpl_init():
// SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2);
// *(volatile uint32_t*)(TIMER1_CLOCK_SRC_MUX_ADDR) = TIMER1_CLOCK_SRC_HFOSC0_CLKOUT;
// SOC_controlModuleLockMMR(SOC_DOMAIN_ID_MAIN, 2);
ClockP_init() (在之后立即调用)将看到已配置的 Timer1 多路复用器并正常继续
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
您能否确认修改后的board-cfg.yaml代码是否已重建到全新签名的 boardcfg blob 中tispl.bin
为了确保更改完全生效、我们 在修改后删除了整个 build 文件夹 board-cfg.yaml。 然而、当重复出现 C7x 挂起问题时、从地址 0x4405F000 读取的所有值 仍然为零。
Add toboard_late_init()in
board/ti/j722s/evm.c
通过上述修改重新编译了 U-Boot、但 C7x 挂起问题仍然存在。 这一次核心卡在 ClockP_init () 内。 从地址 0x4405F000 读取的值 保持为零。 下图显示了通过 CCS 捕获的其他地址的值:

上面提到的所有地址都是物理地址。
此致、
Qiang Leo
尊敬的 Shabary S Sundar:
您能尝试在 CCS 中连接到 WKUP R5F 内核并转储0x4405F000长度吗0x1000?
我们针对物理地址执行了连接测试、所有回读均返回零。 您能否告知我们是否需要同时替换 tiboot3 和 uboot.img?
您还能尝试从 C7x 调用 Board_init 进行检查吗?
Board_init() C7x 侧的函数实现为空。

我使用的 SDK 版本可能不匹配;我使用的是 SDK 10.0.0.8 (ti-processor-sdk-linux-adas-j722s-evm-10_00_00_08)。
此致、
Qiang Leo
您好、Qiang Leo、
我已重现 C7x 挂起问题并将地址 0x4405F000 处的寄存器内容保存到文件中tifs_trace.bin。 相关日志的屏幕截图附在下面。
谢谢您的日志、让我详细介绍这些日志、然后返回给您。 为了在获取 TIFS 跟踪之前明确说明、您已恢复我们之前应用的所有调试步骤、此跟踪属于导致挂起的原始代码?
此致、
Shabary S Sundar
尊敬的 Diwakar:
Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF60 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF68 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF6C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF74 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF7C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF80 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF88 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF90 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF98 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF9C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFA4 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFAC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFB0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFB8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFC0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFC8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFCC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFD4 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFDC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFE0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFE8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFF0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFF8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFFC 0x0 0xFF81AD4 0x4 1020100 0x30000 0x5EFB0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFB8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFBC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFC4 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFCC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFD0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFD8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFE0 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFE8 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFEC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFF4 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EFFC 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF28 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF2C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF30 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF38 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF3C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF44 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF4C 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF54 0x0 0xFF81AD4 0x4 Exception addr 0x45B00000 FWL Exception 0x1020100 0x30000 0x5EF58 0x0 0xFF81AD4 0x4
此致、
Qiang Leo
尊敬的 Diwakar:
是的。 SOC_controlModuleUnlockMMR() 引导期间、C7x 内核在该功能中间歇性挂起。 根据技术支持工程师的建议、我启用了两种调试配置: trace_dst_enables 和 trace_src_enables。 之后、我通过 USB 连接到电路板上的 R5 内核、并使用 CCS 捕获了存储器日志。
此致、
Qiang Leo
嗨、Qiang Leo
是的。SOC_controlModuleUnlockMMR()引导期间、C7x 内核在该功能中间歇性挂起。 根据技术支持工程师的建议、我启用了两种调试配置:trace_dst_enables和trace_src_enables。 之后、我通过 USB 连接到电路板上的 R5 内核、并使用 CCS 捕获了内存日志。

我们需要查看的内存范围为 0x4405F000 到 0x4406F000 、如果我们跨越该边界并查看 TIFS 存储器、则会出现异常。
此致
Diwakar
尊敬的 Diwakar:
我再次重现了 C7x 挂起问题、并将地址 0x4405F000 的日志保存如下。您能帮我找出 C7x 挂起问题的根本原因吗?
8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1015 0x490BC602 0x435EC602 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410015 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1016 0x490BC603 0x435EC603 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410016 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1017 0x490BC604 0x435EC604 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410017 0x4003007 0x4400A08 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1018 0x490BC605 0x435EC605 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410018 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1019 0x490BC606 0x435EC606 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410019 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A101A 0x490BC607 0x435EC607 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x4341001A 00 0x4B08003C 0x4B110016 0x4B120000 0x421000 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F80001C 0x4C40001C 0x4F8A00FF 0x4F8B0001 0x4F80001C 0x4C40001C 0x4B070000 0x4B08003C 0x4B110017 0x4B120000 0x421110 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x41070000 0x41080004 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x421110 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x41070000 0x41080004 0x4F8A00FF 0x4F8B0001 0x4F80001A 0x4100001A 0x42C000 0x82000C 0x42C400 0x82000C 0x42C400 0x82000C 0x42C101 0x82000C 0x42C100 0x82000C 0x42C000 0x82000C 0x42C400 0x82000C 0x42C000 0x82000C 0x42C400 0x82000C 0x42C400 0x82000C 0x42C101 0x82000C 0x42C100 0x82000C 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4540001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A4600 0x490B9013 0x451E4600 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4500001E 0x45010013 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1013 0x490BC600 0x435EC600 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410013 0x421280 0x82000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4380001E 0x4A54000C 0x4A53000C 0x4A530024 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x4A54000C 0x4F8A00FF 0x4F8B0001 0x4F800019 0x49000019 0x490A1014 0x490BC601 0x435EC601 0x4F8A00FF 0x4F8B0001 0x4F80001E 0x4340001E 0x43410014 0x421280 0x82000C 0x4F
此致、
Qiang Leo
嗨、Qiang Leo
[报价 userid=“646568“ url=“~/support/processors-group/processors/f/processors-forum/1644133/tda4ven-q1-tda4ven-c7x-clock-startup-initialization-fault/6375327我再次重现了 C7x 挂起问题、并将地址 0x4405F000 的日志保存如下。您能帮我找出 C7x 挂起问题的根本原因吗?
[/报价]让我来看看这一点,并将很快更新你,从初始了解TIFS 跟踪 0x4405F000 显示 TIFS 是健康和持续处理请求.
此致、
Shabary S Sundar
您好 、Qiang Leo、
我再次重现了 C7x 挂起问题并将日志从地址 0x4405F000 保存如下。您能帮我找到 C7x 挂起问题的根本原因吗?
您共享的新跟踪不会显示任何防火墙例外。
由于暂停 U-Boot 倒计时会抑制挂起点、从而导致 C7x init 和 Linux Remoteproc/DM 活动之间的引导时争用。 为了确认和隔离、您能否 在 boot U-Boot bootcmd 中之前添加一个睡眠状态。 如果挂起消失、我们可以确认比赛条件。
此致、
Shabary S Sundar
尊敬的 Shabary S Sundar:
很抱歉晚才回复。 在通过在 U-Boot 中添加延迟进行测试时、我发现 C7x linker.cmd 文件中定义的 DDR 存储器区域 (C7X_DDR_space) 存在越界问题。 在程序启动期间、固件将以一定的概率访问非法的超出范围存储器地址、从而导致程序挂起。 修复此问题后、无法再重现挂起问题。
此致
Qiang Leo