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.

[参考译文] TDA4VM-Q1:在高温情况下发生 SR 2.0 引导失败问题

Guru**** 2427060 points
Other Parts Discussed in Thread: TDA4VM, TDA4VM-Q1

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1452322/tda4vm-q1-sr-2-0-booting-fail-issue-occurred-at-high-temp-situation

器件型号:TDA4VM-Q1
主题中讨论的其他器件:TDA4VM

工具/软件:

尊敬的专家:

TDA4VM SR2.0 在高温条件下会出现严重的启动故障、 以下是具体的详细信息

  • 器件:TDA4VM-Q1
  • 测试的版本:SR1.1 和 SR2.0
  • 测试环境:在 85°C 的箱内进行开/关测试(1 分钟开/ 1 分钟关)

观察到的行为

  • SR1.1 板:正常运行(电流消耗~2.0A)
  • SR2.0 板:启动故障(电流消耗~1.4A)

测试结果

  1. 室温:
    • SR1.1 和 SR2.0 均正常运行
  2. 高温 (85°C):
    • SR2.0 在执行 1-2 次操作后失败
    • AP 停止工作
    • 发生 OSPI 读取失败
    • 在两个不同的 SR2.0 主板上经过验证、结果相同

可能性技术分析

  • 该问题似乎与高温下的 OSPI 块阻抗变化有关
  • 似乎超出了自动调节范围、导致读取失败
  • SR1.1 和 SR2.0 之间的可能内部阻抗变化

问题

  1. 这是否是 SR2.0 在高温条件下的已知问题?
  2. 是否建议对 OSPI 接口电阻值进行任何修改?
  3. SR1.1 和 SR2.0 在 OSPI 块特性方面有哪些具体差异?
  4. 是否有针对此问题的固件更新或权变措施?

我们非常感谢您为解决这一影响我们生产环境的关键问题提供指导。

 

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

    此外、我们还将共享我们获取的日志。

    我们检查 AP-MCU UART、确认 NOR 闪存读取失败。 (AP-VPU UART 不显示任何内容)

    日志:

    [SBL 13:25:51.879] 2024年12月11日 修订版本:01.00.10.00 (2024 年 12 月 2 日 — 19:15:31)
    [ 2024年12月11日 13:25:51.925]
    2024年12月11日 13:25:51.925][boot_part]第一个空间引导开始
    [ 2024年12月11日 13:25:51.974]
    [TIFS 13:25:52.037] 2024年12月11日 版本:20.8.7-v2020.08d_plus_inf_tmout
    [ 2024年12月11日 13:25:52.088]
    [ 2024年12月11日 13:25:52.088]
    [ 2024年12月11日 13:25:52.088]
    2024年12月11日 13:25:52.102]##时钟监控禁用..
    [ 2024年12月11日 13:25:52.134]
    2024年12月11日 13:25:52.166] Board_flashRead 失败!

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

    您好、

    请告诉我们您正在使用哪个 SDK 版本?  

    此致、

    Brijesh

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

    您好、

    我们使用 SDK 7.1 (PDK Jacinto 07.01)

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

    您好、

    此外、您是否可以在 PHY 调优算法中启用分析代码并共享该算法的输出? 我们想看看调优是否成功、如果未成功、它会在哪里失败?  

    此致、

    Brijesh

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

    你好、Sungjun

    您可以  通过  在中启用以下宏来获取有关 OSPI 调优的日志 nor_spi_phy_tune.c

    //#undef NOR_SPI_TUNE_DEBUG

    #define NOR_SPI_TUNE_DEBUG

    您可以尝试共享日志吗?

    谢谢你。

    此致、

    Johnny

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

    您好、

    这是#define NOR_SPI_TUNE_DEBUG 之后的日志

    SBL 修订版本:01.00.10.00 (2024 年 12 月 24 日 — 12:03:38)
    [BOOT_PART]开始第一个空间引导
    TIFS 版本:20.8.7-v2020.08d_plus_inf_tmout

    ##时钟监控不能...


    在温度 41°C 下快速调优
    左下方位于 txDLL、rxDLL 为 3、0 至 17、10、rdDelay 为 1
    右上角的 txDLL、rxDLL 为 18、11 至 52、39、rdDelay 为 2
    调优以 109 个步骤完成
    将 PHY 调优到 txDLL、rxDLL 为 36、26、rdDelay 为 2


    在温度 42°C 下快速调优


    在温度 43°C 下快速调优
    左下方位于 txDLL、rxDLL 为 3、0 至 17、10、rdDelay 为 1
    右上角的 txDLL、rxDLL 为 18、11 至 52、39、rdDelay 为 2
    调优以 109 个步骤完成
    将 PHY 调优到 txDLL、rxDLL 为 36、26、rdDelay 为 2


    在温度 43°C 下快速调优


    在温度 43°C 下快速调优


    在温度 43°C 下快速调优


    在温度 43°C 下快速调优


    在温度 43°C 下快速调优


    在温度 44°C 下快速调优


    在温度 44°C 下快速调优
    已引导[FW_PART] PART_A 空间、41cace50
    Boot App:以 60 usec 的速度启动
    Boot App:启动的内核总数= 8
    Boot App:552781 用例中的 booted Core ID #6
    Boot App:552988 用例中的 booted Core ID #7
    Boot App:754151 用例中的 booted Core ID #8
    Boot App:754359 用例中的引导内核 ID #9
    Boot App:754543 用例中的 booted Core ID #10
    Boot App:754721 用例中的 booted Core ID #11
    Boot App:755383 用例中的 booted Core ID #12
    Boot App:1492308 用例中的引导内核 ID #0

    MCU 引导任务在 59 个用例中开始、在 82109457 用例中完成

    谢谢。

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

    您好、

    但 此日志似乎源于成功运行。 我看到所有内核都启动正常、引导完成 时显示消息“MCU 引导任务在 59 个用例下开始、在 82109457 用例下完成“。  

    引导失败时是否有类似的日志?

    此致、

    Brijesh

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

    您好、

    抱歉、上面的日志是在室温下检查的。

    在高温下、会出现以下日志。

    SBL 修订版本:01.00.10.00 (2024 年 12 月 24 日 — 12:03:38)
    [BOOT_PART]开始第一个空间引导
    TIFS 版本:20.8.7-v2020.08d_plus_inf_tmout

    ##时钟监控不能...


    在温度 54°C 下快速调优
    rxLow 和 rxHigh 位于相同的 rdDelay 上
    无法找到 TX 最大值
    Board_flashRead 失败!

    我们通过将温度升高到 85 度进行测试、但电路板无法从 54 度引导。
    最高温度下的故障日志如下所示。

    SBL 修订版本:01.00.10.00 (2024 年 12 月 24 日 — 12:03:38)
    [BOOT_PART]开始第一个空间引导
    TIFS 版本:20.8.7-v2020.08d_plus_inf_tmout

    ##时钟监控不能...


    在温度 99°C 下快速调优
    rxLow 和 rxHigh 位于相同的 rdDelay 上
    无法找到 TX 最大值
    Board_flashRead 失败!

    谢谢。

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

    尊敬的 Sungjun Lim:

    在文件 packages\ti\board\tux\flash\nor\ospi\nor_spi_phy_tune.h 中、您能否尝试增大窗口范围(如下所示)、看看它是否有助于查找 src 最大值?

    define NOR_SPI_PHY_TXDLL_LOW_WINDOW_START ( 0 u)
    define NOR_SPI_PHY_TXDLL_LOW_WINDOW_END ( 127. u)

    define NOR_SPI_PHY_TXDLL_HIGH_WINDOW_START ( 0 u)
    define NOR_SPI_PHY_TXDLL_HIGH_WINDOW_END ( 127. u)

    此致、

    Brijesh

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

    您好、 Brijesh

     现在、我正在使用大规模生产环境中制造的新样片进行重新测试。

    这就是为什么 现在推迟测试结果的原因。

    当我获得新的测试结果时、我将使用结果更新此查询

    大家都知道,韩国新年假期将 在这个周末开始 nextweek。

    所以我在 2 月的第一周分享结果

    谢谢。

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

    谢谢 Jisung、我将等待您的更新。  

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

    Jisung、请提供更新、我们将在 30 天后关闭主题但未更新、谢谢 Dave C

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

    您好 Dave、

    感谢您对此问题的关注。

    目前的情况如下。

    所有样片均已 应用 SR2.0 TDA4VM。

    • 样品总数:8ea
    • 测试设置
      • 温度:+85
      • 开/关:2 分钟(每个)
    • 测试结果
      • 通行证:6ea
      • 失败:2ea

    因此、 我们将 Brijesh 提供的 TX 最大值应用于未通过的样本并进行了测试。

    结果通过(在相同的测试环境下)。

    但是、我们观察到启动时间增加了约 20ms。

    我们还能尝试什么?

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

    尊敬的 Jisung:

    现在、我们需要了解它通过的窗口、然后确定围绕该通过点的窗口范围。 这应该有助于减少启动时间。  

    我们能否 首先在 OSPI 中启用调试配置文件来找出通过点?

    此致、

    Brijesh

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

    林成均

    您好 Sungjun、

    您能帮助我满足 Brijesh 的要求吗?

    Brijesh Jadav

    您好、Brijesh

    您能 向我们解释一下到底需要做什么吗?

    THX。

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

    请在 SPI 调优算法中启用日志记录。  

    此致、

    Brijesh

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

    您好、Brijesh、

    您的意思

      | 在中启用以下宏  nor_spi_phy_tune.c

      | //#undef NOR_SPI_TUNE_DEBUG

      | #define NOR_SPI_TUNE_DEBUG

    “你说什么?

    谢谢。

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

    尊敬的 Sungjun Lim:

    是的、 您是否可以在工作案例中启用此标志并运行测试用例? 我们来获取通过窗口的位置。  

    此致、

    Brijesh

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

    您好、 

    您在此查询中请求的标志已启用。

    TDA4VM 唤醒时是否需要完整日志?

    如果是的话、 柳宰洪

    请提供启用了标记的日志。

    THX

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

    是的、我需要完整日志才能确定它通过的窗口位置。  

    此致、

    Brijesh

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

    您好、 Brijesh Jadav

    这是测试用例的完整日志

    [SBL 2025年02月13日 版本:01.00.10.00 (2025 年 1 月 15 日 — 16:20:47)
    2025年02月13日 18:42:48.305][BOOT_PART]开始第一个空间引导
    [TIFS 18:42:48.423] 2025年02月13日 版本:20.8.7-v2020.08d_plus_inf_tmout
    [ 2025年02月13日 18:42:48.460]
    2025年02月13日 18:42:48.460]##时钟监控不可用...
    [ 2025年02月13日 18:42:48.549]
    [ 2025年02月13日 18:42:48.549]
    2025年02月13日 18:42:48.549]温度为 83°C 时快速调优
    [CCS 2025年02月13日 18:42:48.579]左下方位于 txDLL、rxDLL 为 3、0 至 10、5、rdDelay 为 1
    [RXDLL 2025年02月13日 18:42:48.664]右上角的 txDLL、rxDLL 的值为 11、6 至 48、35、rdDelay 为 2
    2025年02月13日 18:42:48.727]调优已通过 249 个步骤完成
    [PHY 18:42:48.755]将 2025年02月13日 调优到 txDLL、rxDLL 的值为 32、22、rdDelay 为 2
    [ 2025年02月13日 18:42:48.823]
    [ 2025年02月13日 18:42:48.823]
    2025年02月13日 18:42:48.823]在温度 84°C 下进行快速调优
    [ 2025年02月13日 18:42:49.008]
    2025年02月13日 18:42:49.026]
    2025年02月13日 18:42:49.026]温度 84°C 时快速调优
    [CCS 2025年02月13日 18:42:49.054]左下方位于 txDLL、rxDLL 为 3、0 至 10、5、rdDelay 为 1
    [ 2025年02月13日 18:42:49.121]右上角的 txDLL、rxDLL 为 11.6 至 48,35、rdDelay 为 2
    2025年02月13日 18:42:49.206]调优已完成 249 步
    [PHY 18:42:49.238]将 2025年02月13日 调优到 txDLL、rxDLL 的值为 32、22、rdDelay 为 2
    [ 2025年02月13日 18:42:49.274]
    [ 2025年02月13日 18:42:49.288]
    2025年02月13日 18:42:49.288]温度为 84°C 时进行快速调优
    [ 2025年02月13日 18:42:49.427]
    [ 2025年02月13日 18:42:49.427]
    2025年02月13日 18:42:49.427]在 85°C 温度下进行快速调优
    [ 2025年02月13日 18:42:49.456]
    [ 2025年02月13日 18:42:49.479]
    2025年02月13日 18:42:49.479]在 85°C 温度下进行快速调优
    [ 2025年02月13日 18:42:49.625]
    [ 2025年02月13日 18:42:49.625]
    2025年02月13日 18:42:49.625]在 85°C 温度下进行快速调优
    [ 2025年02月13日 18:42:49.667]
    [ 2025年02月13日 18:42:49.667]
    2025年02月13日 18:42:49.667]在温度为 86°C 时进行快速调优
    [ 2025年02月13日 18:42:49.718]
    [ 2025年02月13日 18:42:49.718]
    2025年02月13日 18:42:49.718]在 85°C 温度下进行快速调优
    [ 2025年02月13日 18:42:49.743]
    [ 2025年02月13日 18:42:49.765]
    2025年02月13日 18:42:49.765]温度为 86°C 时快速调优
    2025年02月13日 18:42:50.312][FW_PART] PART_A 已引导空间、a.
    [ 2025年02月13日 18:42:58.364]:从 61 usec 开始
    [引导 应用程序 2025年02月13日 18:42:58.393]:引导的内核总数= 8.
    2025年02月13日 18:42:58.425]引导应用程序:在 553559 用例中引导的核心 ID #6
    2025年02月13日 18:42:58.475]引导应用程序:在 553765 用例中引导的核心 ID #7
    2025年02月13日 18:42:58.509]引导应用程序:754528 个用例中的引导内核 ID #8
    2025年02月13日 18:42:58.561]引导应用程序:754734 用例中的引导内核 ID #9
    2025年02月13日 18:42:58.609]引导应用程序:在 754919 用例中引导的内核 ID #10
    2025年02月13日 18:42:58.667]引导应用程序:755102 用例中的引导内核 ID #11
    2025年02月13日 18:42:58.715]引导应用程序:在 755753 用例中引导的核心 ID #12
    2025年02月13日 18:42:58.746]引导应用程序:1485309 用例中的引导内核 ID #0
    [ 2025年02月13日 18:42:58.803]
    [MCU 引导任务在 59 个用例中开始并在 82057259 个用例中完成。2025年02月13日 18:42:58.814]

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

    你好、Jisung Hyun、

    您是否可以尝试 按如下方式修改#define *_END 值以缩短启动时间?

           define NOR_SPI_PHY_TXDLL_LOW_WINDOW_START (0U)
           #define NOR_SPI_PHY_TXDLL_LOW_WINDOW_END (63U)       

        #define NOR_SPI_PHY_TXDLL_HIGH_WINDOW_START (63U)
        define NOR_SPI_PHY_TXDLL_HIGH_WINDOW_END (0U)

    此致、 Lloyd

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

    你好、Jisung Hyun、  

    您是否对修改调谐范围的实验有任何更新?  

    为了进行仔细检查、 我可以问您 SDK 上是否使用了以下补丁吗?   

     e2e.ti.com/.../0001_2D00_PDK_2D00_9328_2D00_OSPI_2D00_Binary_2D00_search_2D00_instead_2D00_of_2D00_linear_2D00_search.patch

    此致、

    Lloyd

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

    尊敬的 Lloyd:

    请按照 T.I 的建议在下面找到测试结果

    • 器件:TDA4VM-Q1
    • 测试版本: SR2.0
    • 测试环境: 在 85°C 的箱中进行开/关循环(1 分钟开/ 1 分钟关)
    • 数量:2ea(初始设置中的失败样本)
    • 测试持续时间:144H(1 周)
    • 测试结果
      • 操作:是
      • 启动时间
        • 初始:1.23s(引导失败)
        • 第一次修改:1.248s(无问题)
        • 第二次修改:1.247s(无问题)

    林成均

    您好 Sungjun、

    您能否查看 Lloyd 关于是否应用了 SDK 补丁的问题

    谢谢。

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

    你好、 Jisung Hyun

    感谢您分享结果。  

    我     是否可以要求您在 nor_spi_phy_tune.c 中为第二次修改启用宏来共享日志?  

    此致、

    Lloyd

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

    柳宰洪

    你好、Jaeyoung、

    如果您从此测试中获取了任何日志、请在此主题中共享它们。

    谢谢、

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

    你好、Lloyd Hwang

    以下是使用第二次修改的日志。

    谢谢。

    [SBL 2025年04月16日 修订版本:01.00.10.00 (2025 年 4 月 9 日 — 11:14:41)
    [ 2025年04月16日 16:56:12.646]
    2025年04月16日 16:56:12.646][boot_part]第一个空间引导开始
    [ 2025年04月16日 16:56:12.680]
    [IFS 16:56:12.747] 2025年04月16日 版本:20.8.7-v2020.08e_j7es_pg2.0_nto
    [ 2025年04月16日 16:56:12.796]
    [ 2025年04月16日 16:56:12.812]
    [ 2025年04月16日 16:56:12.812]
    [ 2025年04月16日 16:56:12.812]#时钟监控不能...
    [ 2025年04月16日 16:56:12.845]
    [FW_PART] 2025年04月16日 16:56:13.835][FW_PART_A 已引导空间、a.
    [ 2025年04月16日 16:56:13.860]
    [引导 应用程序 2025年04月16日 16:56:21.862]:以 60usec 启动
    [ 2025年04月16日 16:56:21.901]
    [引导 应用程序 2025年04月16日 16:56:21.901]:引导的内核总数= 8
    [ 2025年04月16日 16:56:21.933]
    [Core 16:56:21.933]引导应用:248613 用例中的引导 2025年04月16日 ID #6
    [ 2025年04月16日 16:56:21.985]
    [Core 16:56:21.985]引导应用程序:在 248819 用例中引导的 2025年04月16日 ID #7
    [ 2025年04月16日 16:56:22.034]
    2025年04月16日 16:56:22.034]引导应用程序:在 369795 用例中引导的内核 ID #8
    [ 2025年04月16日 16:56:22.083]
    [Core 16:56:22.083]引导应用程序:在 370001 用例中引导的 2025年04月16日 ID #9
    [ 2025年04月16日 16:56:22.118]
    [Core 16:56:22.118]引导应用程序:在 370194 用例中引导的 2025年04月16日 ID #10
    [ 2025年04月16日 16:56:22.170]
    [Core 16:56:22.170]引导应用程序:在 370374 用例中引导的 2025年04月16日 ID #11
    [ 2025年04月16日 16:56:22.217]
    [Core 16:56:22.217]引导应用:在 371024 个用例中引导的 2025年04月16日 ID #12
    [ 2025年04月16日 16:56:22.270]
    [引导 应用程序:973309 用例中的 2025年04月16日 16:56:22.270]引导应用程序:已引导的核心 ID #0
    [ 2025年04月16日 16:56:22.300]
    [ 2025年04月16日 16:56:22.310]
    [ 2025年04月16日 16:56:22.310]
    [MCU 引导任务在 59 个用例中开始并在 75501334 用例中完成。2025年04月16日 16:56:22.310
    [ 2025年04月16日 16:56:22.383]
    [ 2025年04月16日 16:56:22.383]
    [SBL 2025年04月16日 版本:01.00.10.00 (2025 年 4 月 9 日 — 11:14:41)
    [ 2025年04月16日 17:00:12.633]
    2025年04月16日 17:00:12.633][BOOT_PART]第一个空间引导开始
    2025年04月16日 17:00:12.671]
    [IFS 17:00:12.739] 2025年04月16日 版本:20.8.7-v2020.08e_j7es_pg2.0_nto
    [ 2025年04月16日 17:00:12.787]
    [ 2025年04月16日 17:00:12.804]
    [ 2025年04月16日 17:00:12.804]
    2025年04月16日 17:00:12.804]##时钟监控不能...
    [ 2025年04月16日 17:00:12.834]
    2025年04月16日 17:00:13.814][FW_PART] PART_A 已引导空间、a.
    2025年04月16日 17:00:13.852]
    2025年04月16日 17:00:21.863]引导应用程序:以 61usec 启动
    2025年04月16日 17:00:21.892]
    2025年04月16日 17:00:21.892]引导应用程序:引导的内核总数= 8.
    [ 2025年04月16日 17:00:21.925]
    2025年04月16日 17:00:21.925]引导应用:在 248813 用例中引导的内核 ID #6
    2025年04月16日 17:00:21.976]
    2025年04月16日 17:00:21.976]引导应用:249019 用例中的引导内核 ID #7
    2025年04月16日 17:00:22.026]
    2025年04月16日 17:00:22.026]引导应用程序:在 371927 用例中引导的内核 ID #8
    2025年04月16日 17:00:22.075]
    2025年04月16日 17:00:22.075]引导应用程序:在 372137 用例中引导的内核 ID #9
    2025年04月16日 17:00:22.109]
    2025年04月16日 17:00:22.109]引导应用程序:在 372324 用例中引导的内核 ID #10
    2025年04月16日 17:00:22.158]
    2025年04月16日 17:00:22.158]引导应用:在 372503 用例中引导的内核 ID #11
    2025年04月16日 17:00:22.208]
    2025年04月16日 17:00:22.208]引导应用程序:在 373162 用例中引导的内核 ID #12
    2025年04月16日 17:00:22.259]
    2025年04月16日 17:00:22.259]引导应用程序:在 973310 用例中引导的内核 ID #0
    [ 2025年04月16日 17:00:22.292]
    2025年04月16日 17:00:22.316]
    2025年04月16日 17:00:22.316]
    [MCU 引导任务在 60 个用例中开始并在 75500317 用例中完成。2025年04月16日 17:00:22.316]

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

    你好、 柳宰荣

    非常感谢。 我可以 通过   在中启用宏来询问您日志吗  nor_spi_phy_tune.c  第 2 次修改如下所示?  

         //#undef NOR_SPI_TUNE_DEBUG

         #define NOR_SPI_TUNE_DEBUG

    此致、

    Lloyd

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

    你好、黄丽玉。

    以下是您请求宏的日志。

    请检查此日志。

    2025年04月24日 12:56:07.893][BOOT_PART]第一个空间引导开始
    [IFS 12:56:08.009] 2025年04月24日 版本:20.8.7-v2020.08e_j7es_pg2.0_nto
    2025年04月24日 12:56:08.049]
    2025年04月24日 12:56:08.049]#时钟监控不能...
    [ 2025年04月24日 12:56:08.137]
    [ 2025年04月24日 12:56:08.137]
    2025年04月24日 12:56:08.137]在温度 91C 下快速调优
    [CCS 2025年04月24日 12:56:08.156]左下角的 txDLL、rxDLL 为 3、0 至 10、5、rdDelay 为 1
    [RXDLL12 2025年04月24日:56:08.263]右上角的 txDLL、rxDLL 的值为 11、6 到 49、36、rdDelay 为 2
    2025年04月24日 12:56:08.311]调优已完成 247 个步骤
    [PHY 12:56:08.344]将 2025年04月24日 调优到 txDLL、rxDLL 为 33、23、rdDelay 为 2
    [ 2025年04月24日 12:56:08.412]
    [ 2025年04月24日 12:56:08.412]
    2025年04月24日 12:56:08.412]温度为 92C 时的快速调优
    [ 2025年04月24日 12:56:08.600]
    [ 2025年04月24日 12:56:08.600]
    2025年04月24日 12:56:08.600]温度 93C 下的快速调优
    [CCS 2025年04月24日 12:56:08.648]左下方位于 txDLL、rxDLL 为 3、0 至 10、5、rdDelay 为 1
    [CCS 2025年04月24日 12:56:08.709]右上角的 txDLL,rxDLL11.6 到 49,36 且 rdDelay 为 2
    2025年04月24日 12:56:08.776]调优已通过 247 个步骤完成
    [PHY 12:56:08.811]将 2025年04月24日 调优到 txDLL、rxDLL 的值为 33、23、rdDelay 调整为 2
    [ 2025年04月24日 12:56:08.859]
    [ 2025年04月24日 12:56:08.859]
    2025年04月24日 12:56:08.859]在温度 93C 下快速调优
    [ 2025年04月24日 12:56:09.004]
    [ 2025年04月24日 12:56:09.004]
    2025年04月24日 12:56:09.004]在 94°C 温度下快速调优
    [ 2025年04月24日 12:56:09.060]
    [ 2025年04月24日 12:56:09.060]
    2025年04月24日 12:56:09.060]温度 93C 下快速调优
    [ 2025年04月24日 12:56:09.209]
    [ 2025年04月24日 12:56:09.209]
    2025年04月24日 12:56:09.209]温度 94C 下快速调优
    [ 2025年04月24日 12:56:09.258]
    [ 2025年04月24日 12:56:09.258]
    2025年04月24日 12:56:09.258]在温度 94°C 下进行快速调优
    [ 2025年04月24日 12:56:09.292]
    [ 2025年04月24日 12:56:09.292]
    2025年04月24日 12:56:09.292]在 94°C 温度下进行快速调优
    [ 2025年04月24日 12:56:09.337]
    [ 2025年04月24日 12:56:09.337]
    2025年04月24日 12:56:09.337]在 94°C 温度下快速调优
    2025年04月24日 12:56:09.913][FW_PART] PART_B 已引导空间、b.
    2025年04月24日 12:56:17.950]引导应用程序:以 61 usec 启动
    2025年04月24日 12:56:17.977]引导应用程序:引导的内核总数= 8.
    2025年04月24日 12:56:18.013]引导应用程序:553729 用例中的引导内核 ID #6
    [Core 12:56:18.060]引导应用程序:553936 用例中的引导 2025年04月24日 ID #7
    2025年04月24日 12:56:18.108]引导应用:在 755672 用例中引导的内核 ID #8
    2025年04月24日 12:56:18.144]引导应用:755878 用例中引导的内核 ID #9
    2025年04月24日 12:56:18.198]引导应用程序:在 756069 用例中引导的核心 ID #10
    2025年04月24日 12:56:18.239]引导应用程序:756252 用例中的引导内核 ID #11
    [Core 2025年04月24日 12:56:18.273] Boot App:booted Core ID #12 at 756899 uses
    2025年04月24日 12:56:18.327]引导应用:在 1488309 用例中引导的内核 ID #0
    [ 2025年04月24日 12:56:18.374]
    [MCU 引导任务在 59 个用例中开始、在 82076004 用例中完成。2025年04月24日 12:56:18.410]

    谢谢你。

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

    嗨、Lloyd、Yoo Jaeyong 先生、

    我与上述日志有点混淆。  

    此论坛共享了三个完整的日志。  

    -在第一个日志中,在大约 2 个月前在下面的链接共享,我看到启动时间是由大约  82057259 用例完成的。 但这里提到的 tifs 版本是 20.8.7、 v2020.08d_plus_inf_tmout。 我们不在 ES2.0 上使用该 TIFS。 这是不正确的日志吗? 还是来自 ES1.1?  

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1452322/tda4vm-q1-sr-2-0-booting-fail-issue-occurred-at-high-temp-situation/5682153#5682153

    -第二个日志,在大约 13 天在下面的链接共享,有正确的 TIFS 版本 ie  20.8.7-v2020.08e_pg2.0_nto,但在这里引导完成 75501334 j7s。 我想我们 将窗口更改为一半、对吧?

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1452322/tda4vm-q1-sr-2-0-booting-fail-issue-occurred-at-high-temp-situation/5781088#5781088

    -第三个日志,大约在 6 天前分享在下面的链接,有正确的 TIFS 版本,即  20.8.7-v2020.08e_j7es_pg2.0_nto,但这里的启动完成在 82076004 用例。

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1452322/tda4vm-q1-sr-2-0-booting-fail-issue-occurred-at-high-temp-situation/5794064#5794064

    那么、第二个和第三个日志之间有什么变化? 您能否确认您已减小第三个日志中的窗口大小? 因为我们可以在第二个日志中清楚地看到引导时间减少了。  

    此致、

    Brijesh

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

    大家好、Brijesh Jadav。

    以下是我的答案

    1.所有日志均为 ES2.0 日志。

    2.第二个和第三个日志相同、但为 TI 申请启用以下 SW 宏除外。

    ->   在中启用宏  nor_spi_phy_tune.c  第 2 次修改如下所示

         //#undef NOR_SPI_TUNE_DEBUG

         #define NOR_SPI_TUNE_DEBUG

    3.我不确定、但 TI 为我们提供了优化的软件更新、以缩短启动时间。
    因此、TI 将更好地知道窗口已减少到一半

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

    您好、Yoo、

    但这是否意味着引导时间的增加是由于日志的增加? 如果引导在  75501334usec 内完成、是否正确并与 ES1.1 匹配?  

    此致、

    Brijesh

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

    您好、Yoo、请回复 Brijesh、如果没有进一步更新、我们将关闭主题 Dave C

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

    由于没有进一步更新而关闭、如果需要进一步的支持、只需回复重新打开、Dave C