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.

[参考译文] TDA4VEN-Q1:TDA4VEN C7X 时钟启动初始化故障

Guru**** 2952510 points

Other Parts Discussed in Thread: SYSCONFIG

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1644133/tda4ven-q1-tda4ven-c7x-clock-startup-initialization-fault

器件型号: 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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shabary S Sundar:

    我将中断禁用和中断状态清除操作都放在 DPL_init () 函数的开头。 但是、系统仍然会卡住。 请注意、DPL_init() 是在 main() 中执行的第一个函数。 这个问题是否实际上不是由中断本身引起的?

    此致、

    Qiang Leo

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、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:

    我错误地点击了“这解决了我的问题“。 此问题 未 解决。 您能否继续提供帮助?

    我添加了代码片段:
    Volatile uint32_t jtagId =*(volatile uint32_t *) 0x00100014U;
    (void)jtagId;
    将出现在解锁 MMR 寄存器之前。 我发现 C7x 内核在读取 JTAG ID 寄存器时挂起、并且 每次都会出现这种现象。这是否由您之前提到的防火墙或 PSC 问题引起?
    此致、
    Qiang Leo
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、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]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    虽然日志指示 C7x 已连接、但实际上 C7x 内核无法正确启动

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、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 通常不会执行的完整防火墙/时钟设置。

    您能否运行此测试:

    1. 重现挂起。
    2. 通过 JTAG 上的 CCS 暂停 C7x_1。
    3. 从 CCS 存储器浏览器中、读取以下两个地址:
      • 0x43000014 —真实 JTAGID(WKUP 域)
      • 0x00100000 —MAIN_CTRL_MMR0 的开始
    4. 分享这两个价值。

    此致、
    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 内存浏览器中:

    1. 连接到 A53 内核(或任何可用内核)
    2. 打开 “View“→“Memory Browser“
    3. 输入地址 0x4405F000
    4. 右键点击→ Save Memory
    5. 将长度设置为 0x1000 (4096 字节)
    6. 另存为 .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—分享以下结果:

    1.  tifs_trace.bin 转储来源 0x4405F000
    2.  devmem2 步骤 5 的输出
    3.  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 的值。
    为了在 U-Boot 和 Linux 两个阶段捕获这两个地址的值、我编写了一个测试脚本。 它会在倒计时期间暂停 U-Boot、首先读取寄存器值、然后恢复 U-Boot 并在进入 Linux 后再次检索这些值。
    但是、该方法无法重现 C7x 挂起问题。 我怀疑暂停 U-Boot 倒计时会改变引导时序、从而使 C7x 固件能够正常加载。
    您的完整 dmesg 输出显示 Remoteproc 连接序列
    dmesg 的输出与以前的日志保持一致。

    此致、

    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 开始之前配置计时器多路复用器。

    更改 1:在 U-Boot 中

    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(具有防火墙访问权限)写入计时器多路复用器。

    更改 2:在 C7x 固件中

    在 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 to board_late_init() in
    board/ti/j722s/evm.c

    通过上述修改重新编译了 U-Boot、但 C7x 挂起问题仍然存在。 这一次核心卡在 ClockP_init () 内。 从地址 0x4405F000 读取的值 保持为零。 下图显示了通过 CCS 捕获的其他地址的值:

    上面提到的所有地址都是物理地址。

    此致、

    Qiang Leo

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 、Qiang Leo、

    通过上述修改重新编译了 U-Boot、但 C7x 挂起问题仍然存在。 这一次核心卡在 ClockP_init () 内。 [/报价]

    让我来看看这个问题、然后再联系您。

    此致、
    Shabary S Sundar

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Qiang Leo、

    从地址 0x4405F000 读取的值 保持为零。 下图显示了通过 CCS 捕获的其他地址的值:

    您可以尝试在 CCS 中连接到 WKUP R5F 内核、转储 0x4405F000 长度、 0x1000? 还可以尝试从 C7x 调用 Board_init 进行检查吗?

    Regards,
    Shabary S Sundar

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 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、
    负责的工程师目前不在办公室。 请预计响应会延迟一天。
    此致、
    Ben

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Qiang Leo、

    您能告知我们是否需要同时替换 tiboot3 和 uboot.img 吗?

    是的、在修改任何 board-cfg.yaml、sec-cfg.yaml、pm-cfg.yaml 或 rm-cfg.yaml 时、可以将 tiboot3.bin、tispl.bin 和 u-boot.img 一起替换。

    此致、
    Shabary S Sundar

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shabary S Sundar:

    我重现了 C7x 挂起问题并将地址 0x4405F000 处的寄存器内容保存到文件中 tifs_trace.bin。 相关日志的屏幕截图附在下面。

    此致、

    Qiang Leo

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Qiang Leo、

    我已重现 C7x 挂起问题并将地址 0x4405F000 处的寄存器内容保存到文件中 tifs_trace.bin。 相关日志的屏幕截图附在下面。

    谢谢您的日志、让我详细介绍这些日志、然后返回给您。 为了在获取 TIFS 跟踪之前明确说明、您已恢复我们之前应用的所有调试步骤、此跟踪属于导致挂起的原始代码?

    此致、
    Shabary S Sundar

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shabary S Sundar:

    是的、我已经删除了以前的调试配置。期待您的回复。

    此致、

    Qiang Leo

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Qiang Leo、

    您能否以文本格式共享迹线、以便我们可以对其进行解析。

    此致
    Diwakar

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、 Qiang Leo

    对不起,我想你误解,我只是需要在一些文件下面的数据,而不是屏幕截图.

     

    此致
    Diwakar
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、 Qiang Leo

    Wkup R5(优先级 ID 212)正在尝试访问 0x5EF7C、这会导致防火墙异常。
    您是否连接到内核并查看了上述地址?  从跟踪来看、您似乎正在从 Wkup R5 执行调试读取操作。
    此致
    Diwakar
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 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:

    我访问的地址确实是 0x4405F000、长度为 0x1000。 我还在“CCS Memory“视图中查看了此地址范围以外的数据。 这是否会触发异常?

    此致、

    Qiang Leo

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Qiang Leo

    我还在“CCS Memory“视图中查看了此地址范围以外的数据。 这是否会触发异常?
    是的、可以。
    此致
    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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Qiang Leo、

    感谢您分享此更新。

    此致、
    Shabary S Sundar