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.

[参考译文] AM2431:尝试将工程更新到 SDK 9.02.01但获得断言

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1383931/am2431-trying-to-update-project-to-sdk-9-02-01-but-getting-assert

器件型号:AM2431
主题中讨论的其他器件:SysConfig

工具与软件:

我正在尝试将我们的项目从 SDK 9.00更新到9.02.01

我将使用新的 SDK 编译引导加载程序和主固件

在启动电路板时、会出现以下错误

引导槽起始地址:0x100000
传输的 TR 响应失败:SRC = 0x60120000、DST = 0x70070000、大小= 64512
断言:0.702190s:ospi/V0/dma/udma/ospi_dma_udma.c:Opiddma_udmaUpdateSubmitTR:242:false 失败!!

Here is the code from the SDK where it fails

    /* Wait for return descriptor in completion ring - this marks transfer completion */
    while(1)
    {
        status = Udma_ringDequeueRaw(Udma_chGetCqRingHandle(chHandle), &pDesc);
        if(UDMA_SOK == status)
        {
            /* Check TR response status */
            CacheP_inv(trpdMem, trpdMemSize, CacheP_TYPE_ALLD);
            trRespStatus = UdmaUtils_getTrpdTr15Response(trpdMem, 1U, 0U);
            if(trRespStatus != CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE)
            {
                DebugP_log("TR Response failed for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
                DebugP_assert(FALSE);
            }
            break;
        }
    }

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

    您好!

    [quote userid="558363" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1383931/am2431-trying-to-update-project-to-sdk-9-02-01-but-getting-assert bootslot start addr:0x100000
    传输的 TR 响应失败:SRC = 0x60120000、DST = 0x70070000、大小= 64512
    断言:0.702190s:ospi/V0/dma/udma/ospi_dma_udma.c:Opiddma_udmaUpdateSubmitTR:242:false 失败!!

    您能否分享完整的启动日志?

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

    如何捕获启动日志?

    这是生产电路板上的串行输出。

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

    您好!

    如果您要进行迁移、我假设您处于开发阶段、因此您可以完全访问电路板和所有日志。 我希望从您的引导加载程序查看完整的引导日志。

    此外、我还希望您启用 Sysfw 跟踪并共享这些日志。

    Sysfw 日志可以按如下方式启用:

    • sources/drivers/sciclient/sciclient_default_boardcfg/am64x/sciclient_defaultBoardcfg.c 中的"#UNDEF SYSFW_TRACE_ENABLE"更改为"#define SYSFW_TRACE_ENABLE"  
    • 使用  make -s -C tools/sysfw/boardcfg 构建电路板配置
    • 在 SBL 中为 MAIN_UART1添加另一个 UART 实例。
    • 构建 SBL。

    此致、

    Prashant

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

    我在 Windows 机器上、当我尝试构建电路板配置文件时、就会得到提示

    ps C:\ti\mcu_plus_sdk_am243x_09_02_00_50> make -s -C tools/sysfw/boardcfg
    makefiles:5:/imports.mak:没有这样的文件或目录
    Makefile:6:/devconfig/devconfig.mak:没有这样的文件或目录
    C:\gnu_unix\usr\local\wbin\make.exe:*** No rules to make target `/devconfig/devconfig.mak’. Stop.  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    C:\GNU_UNIX\usr\local\wbin\make.exe:*** No rule to make target `/devconfig/devconfig.mak。  停止.

    看起来您可能正在使用旧版本的 make。 我在过去见过这种情况。

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1264237/am62a7-why-does-it-can-not-identify-this-command-abspath-of-make-in-windows

    您可以使用 CCS 安装程序随附的 gmake 实用程序或至少使用 make v4.x

    此致、

    Prashant

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

    很抱歉响应缓慢。 我在追其他一些问题。

    我现在正在使用新版本的 gmake (4.1)、但仍然无法构建电路板配置
    我现在看到的是这个错误

    One of the boardcfg files provided do not exist, exiting blob creation ...
    makefile:131: recipe for target 'sciclient_boardcfg' failed
    gmake: *** [sciclient_boardcfg] Error 2

    这是 makefile 中它所不喜欢的行

        $(PYTHON) $(BLOB_GEN) --sw-rev 1 --devgrp $(DEVGRP_MAIN) --bcfg $(BCFG) --bcfg-rm $(BCFG_RM) --bcfg-pm $(BCFG_PM) --bcfg-sec $(BCFG_SEC) --output-file $(BCFG_BLOB_FILE)

    我还不能归档它所抱怨的。

    ========

    另一个注意事项是、我已经能够在 SDK 中添加调试语句并重新编译 SBL 目标
    当引导加载程序尝试对存储在 ospi 上的固件进行哈希处理时、就会发生我们的故障。
    我们通过调用函数 Flash_READ ()来执行64k 读取到缓冲区中。

    在文件 ospi_dma_udma.c 中、调用函数 OspiDma_udmaCopy、它将64k 读取分为两个大小为64512和1024的调用、并调用函数 OspiDma_udmaUpdateSubmitTR ()。
    该函数调用 udma_ringDequeueRaw (),直到返回 udma_Sok ,然后它检查 UdmaUtils_getTrpdTr15Response ()并寻找 CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE 的返回。

    执行散列检查时,第一个64k 块被成功读取,但在读取第二个64k 块时,UDMA_ringDequeueRaw ()返回 UDMA_SOK,但当调用 UdmaUtils_getTrpdTr15Response ()时,返回 CSL_UDMAP_TR_RESPONSE_STATUS_TRANSFER_ERR。

    我在9.00至9.02.01中比较了这些 SDK 源文件、它们是相同的、因此包含的二进制文件中肯定有一些内容发生了更改、导致读取失败。

    Jeff

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我现在正在使用新版本的 gmake (4.1)、但仍然无法构建电路板配置
    我现在看到此错误

    您能否分享完整的构建日志?

    在这里检索 SYSFW 日志很重要、因为可能由于某种原因而存在防火墙异常、该异常可能会阻止对 SRAM 地址0x70000的访问。

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

    另一个注意事项是、前两个 SRAM 组(0x70000000-0x70080000)应保留用于 SBL、如所示

    那么、为什么 SBL 会将应用程序加载到地址0x70070000?

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

    这是完整的日志

    c:\ti\mcu_plus_sdk_am243x_09_02_01_05>gmake -s -C tools/sysfw/boardcfg
    One of the boardcfg files provided do not exist, exiting blob creation ...
    makefile:131: recipe for target 'sciclient_boardcfg' failed
    gmake: *** [sciclient_boardcfg] Error 2

    c:\ti\mcu_plus_sdk_am243x_09_02_01_05>

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

    我们有一个64k 的全局缓冲区、用于读取闪存数据块以计算哈希值。 第一个64k 块被成功读取、这是我们第二次尝试读取失败

    #define BOOTFLASH_BLOCK_SIZE (64U * 1024U)
    unsigned char bootloader_buffer[bootflash_block_size];

    相同的代码可以完美地与 SDK 9.00搭配使用

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid="558363" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1383931/am2431-trying-to-update-project-to-sdk-9-02-01-but-getting-assert/5312298 #5312298"]c:\ti\mcu_plus_sdk_am243x_09_02_01_05>gmake -s -C tools/sysfw/boardcfg

    抱歉、我的错。 我们需要传递一个额外的参数 soc=am243x

    gmake -s -C tools/sysfw/boardcfg SOC=am243x

    请注意、SYSFW 日志将出现在 MAIN_UART1上。 因此、SBL 应在其 SysConfig 中为 UART1添加一个 UART 实例。

    如果您没有可用的 MAIN_UART1、也可以从存储器缓冲区收集 SYSFW 日志

    https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html?highlight=issue%20hash%20operation#trace-memory-buffer-location

    此致、

    Prashant

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

    我添加了 SOC=am243x 和 gmake 运行。 我重建了工程、但在 UART 上没有获得任何额外的输出。

    我还尝试了添加 DEVICE_TYPE=HS (因为我们使用的是 HS_SF 芯片)、但它也没有添加任何额外的输出。

    我们已经在项目中定义了一个 UART、因此我将其重命名为 MAIN_UART1
    这是它现在设置的内容(我的 DebugP_log()消息正在出现,但这就是全部)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我还尝试添加 device_type=hs (因为我们使用的是 HS_SF 芯片)、但它也没有添加任何额外输出。

    请保持 GP 仅限。 HS 仅适用于 HSSE。

    我们已在项目中定义了 UART、因此我将它重命名为 MAIN_UART1

    您刚刚更改了在源代码的索引中直接使用的标识符。 我的意思是、你必须用"+Add"添加一个额外的 UART、然后确保将 UART 实例设置为 USART1

    DebugP_LOG 打印将像往常一样位于 UART0上、而 SYSFW 日志(如果启用)将位于 UART1上。 这些将是 PC 上的不同端口。

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

    我添加了另一个 UART、如上所示。
    我正在监视的当前端口不显示任何额外输出。 我不确定要在 PC 上使用哪个其他端口。 我要测试的板是生产板、我有一根 FTDI 电缆连接到它的串行端口。 我看到 XDS 增加了2个串行端口、但我看不到其中任何一个端口的数据。
    我现在还注意到、在板打印出部分错误消息并不断重复后、它将复位

    引导加载程序 v3
    引导槽起始地址:0x100000
    传输的 TR 响应失败:SRC = 0x6012ð

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

    您好!

    UART1是否启用取决于您的电路板原理图。 您可能需要连接一些跳线或其他东西来暴露 UART1端口。

    在任何情况下、我们都不要忘记 UART。 您能否使用调试器从内存缓冲区中获取 SYSFW 日志?

    另一条注意事项是、如果您不使用 DMA 传输数据、是否会出现任何问题或电路板按预期一路引导?

    此致、

    Prashant

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

    我们的 UART1已连接到板上的另一个处理器、因此可能无法正常工作。

    我确实捕获了内存缓冲区。 我以多种格式保存了它(TI Raw 和 COFF 看起来非常相似)。
    (如何附加日志?)

    我关闭了 DMA、我们的代码就通过了哈希校验。 它会进行其他检查失败、但它不在 SDK 中。 在没有 DMA 的情况下完成此步骤确实要花费更长的时间(我们必须将其打开以满足系统其他部分的时序要求)。

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

    Here is the TI Raw Data trace
    
    0x60C000B9
    0x60C000B2
    0xC20102
    0xC20024
    0x61800102
    0x61C00092
    0x62000001
    0xC2010D
    0xC20024
    0x6180010D
    0x61C00092
    0x61276CB2
    0xC2010C
    0xC20024
    0x6180010C
    0x61C00092
    0x61276CB2
    0x61276CB2
    0xC20101
    0xC20024
    0x61800101
    0x61C0007F
    0xC20104
    0xC20024
    0x61800104
    0x61C0007F
    0xC20103
    0xC20024
    0x61800103
    0x61C0007F
    0xC20100
    0xC20024
    0x61800100
    0x61C0007F
    0x62000000
    0x60C0007A
    0xC20102
    0xC20024
    0x61800102
    0x61C0007F
    0x62000001
    0xC2010D
    0xC20024
    0x6180010D
    0x61C0007F
    0x7111FC01
    0xC20102
    0xC20024
    0x61800102
    0x61C0007F
    0x62000002
    0x6140047A
    0xC2010D
    0xC20024
    0x6180010D
    0x61C0007F
    0x6117FC3F
    0xC2010C
    0xC20024
    0x6180010C
    0x61C0007F
    0x6117FC3F
    0x6117FC3F
    0xC21500
    0xC20024
    0x4F4E00FF
    0x4F4A001A
    0x4F4B0020
    0x4F4606A0
    0x4F4C000C
    0x4F4D0006
    0x4F4F0000
    0x4F500000
    0xC21500
    0xC20024
    0x4F4E00FF
    0x4F4A001A
    0x4F4B0022
    0x4F4606A2
    0x4F4C0006
    0x4F4D0006
    0x4F4F0000
    0x4F500000
    0xC21500
    0xC20024
    0x4F4E00FF
    0x4F4A001A
    0x4F4B0021
    0x4F4606A1
    0x4F4C0006
    0x4F4D0006
    0x4F4F0000
    0x4F500000
    0xC21500
    0xC20024
    0x4F4E00FF
    0x4F4A001C
    0x4F4B000D
    0x4F46070D
    0x4F4C0210
    0x4F4D0100
    0x4F4F0000
    0x4F500000
    0xC21500
    0xC20024
    0x4F4E00FF
    0x4F4A001C
    0x4F4B000A
    0x4F46070A
    0x4F4C002C
    0x4F4D000E
    0x4F4F0000
    0x4F500000
    0xC21110
    0xC20024
    0x41070000
    0x410800BF
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0x4F01000C
    0x4F06068D
    0x4F0A0024
    0x4101000C
    0x410C0001
    0x410D7008
    0x410E1D00
    0x410F0000
    0x41100001
    0x41110000
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    0x41070000
    0x410800BF
    0x4F8A00FF
    0x4F8B0001
    0x4F80001A
    0x4100001A
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42FD4
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42FD4
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42F7C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42F7C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42F7C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x42F7C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44000
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44000
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44000
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44000
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44000
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x4427C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x44C04
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x4539C
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x45D24
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x464A8
     0x0
     0x421BD4
     0x4
    
    Exception addr  0x45B00000
    FWL Exception  0x1020100
     0x30000
     0x46E34
     0x0
     0x421BD4
     0x4
    
    4001
    0x63D02002
    0x64504001
    0x63100016
    0x64502002
    0x63D06002
    0x64506002
    0x63D08002
    0x64508002
    0x63C00050
    0x64400050
    0x63C02001
    0x64402001
    0x6300005C
    0x63C04003
    0x64404003
    0x63C06004
    0x64406004
    0x63C10004
    0x64410004
    0x63C1C002
    0x6441C002
    0x63C30004
    0x64430004
    0x63C32003
    0x64432003
    0x68400000
    0x60C000A3
    0xC20102
    0xC20024
    0x61800102
    0x61C0184B
    0x62000007
    0xC2010D
    0xC20024
    0x6180010D
    0x61C0184B
    0x612B7C88
    0xC2010C
    0xC20024
    0x6180010C
    0x61C0184B
    0x612B7C88
    0x612B7C88
    0xC20101
    0xC20024
    0x61800101
    0x61C00098
    0xC20104
    0xC20024
    0x61800104
    0x61C00098
    0xC20103
    0xC20024
    0x61800103
    0x61C00098
    0xC20100
    0xC20024
    0x61800100
    0x61C00098
    0x62000000
    0x60C000BA
    0x60C000B3
    0xC20102
    0xC20024
    0x61800102
    0x61C00098
    0x62000001
    0xC2010D
    0xC20024
    0x6180010D
    0x61C00098
    0x61276CB3
    0xC2010C
    0xC20024
    0x6180010C
    0x61C00098
    0x61276CB3
    0x61276CB3
    0xC20101
    0xC20024
    0x61800101
    0x61C00092
    0xC20104
    0xC20024
    0x61800104
    0x61C00092
    0xC20103
    0xC20024
    0x61800103
    0x61C00092
    0xC20100
    0xC20024
    0x61800100
    0x61C00092
    0x62000000

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

    感谢分享日志!!

    有一些防火墙例外、但它们似乎与问题无关。 我也不确定这些日志是否正确、因为生成防火墙例外的事务使用调试标志(即调试事务)标记。 您是否在调试器的控制下运行 SBL?

    由于 v9.0已完全可用、因此我也希望您尝试一下以下步骤:

    • 在 make 命令中生成没有"-s"标志的 v9.2 SBL 以生成完整的编译日志。
    • 在这些日志中、您将找到一个 rom_image_gen.py 命令来生成 ROM 可引导 SBL 映像(tiimage)。
      ❯ make -C examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang scrub all | grep rom_image_gen
      python3 /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/tools/boot/signing/rom_image_gen.py --swrv 1 --sbl-bin /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_ospi.release.bin --sysfw-bin /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/soc/am64x_am243x/sysfw-hs-fs-enc.bin --sysfw-inner-cert /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/soc/am64x_am243x/sysfw-hs-fs-enc-cert.bin --boardcfg-blob /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/sciclient_default_boardcfg/am243x/boardcfg_blob.bin --sbl-loadaddr 0x70000000 --sysfw-loadaddr 0x44000 --bcfg-loadaddr 0x7B000 --key /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/tools/boot/signing/rom_degenerateKey.pem --rom-image /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_ospi.release.hs_fs.tiimage
    • 将此命令按原样替换、仅替换 SBL 二进制路径(--sbl-bin)、以指向 Raw v9.0 SBL 二进制文件。
    • 运行命令以生成 ROM 可引导 SBL 映像(tiimage)。

    如果在上述命令之后生成的可启动 SBL (tiimage)导致预期的引导、则这意味着 v9.2 SBL 二进制文件有问题、仅其他组件(主要是电路板配置)有问题。

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

    我使用 SDK 9.00构建了引导加载程序并从上面运行 make。 然后我从我的版本中将-sbl-bin 路径替换为-sbl-bin 路径、并运行 python 脚本。 我将创建的 tiimage 刷写到 am243上、它成功完成了引导加载程序。

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

    您好!

    我将创建的 tiimage 刷写到 am243中、它成功通过了引导加载程序。

    为了确认一点、这个成功引导的 SBL tiimage 是使用 SDK v9.0中的 SBL 二进制文件和 SDK v9.2中的其他组件构建的? 如果 SBL tiimage 是使用 SDK v9.2中的所有组件构建的、是否引导再次失败?

    在后一种情况下、您能否共享图像?

    此致、

    Prashant

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

    有。 我甚至先重新安装了9.02.01 SDK (因此它没有我所做的任何更改)。 我进行了 ti-arm-clang 擦除全部操作、并使用它显示的命令将--sbl-bin 路径替换为从9.00版本生成的 bootloader.bin 文件、然后运行 python 命令。 将生成的文件放在我们的电路板上、然后通过引导加载程序的哈希检查部分进行创建。

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

    您好!

    今天、我进行了一些测试、这些测试与您的设置基本相同、这意味着多次使用 Flash_READ 读取64K DMA、并且使用 SDK v9.2可以成功执行。 这主要是特定于您的引导加载程序的内容。

    由于前64K 块读取成功、DMA 没有理由失败。

    让我在 DMA 专家中循环查看一些输入!!

    此致、

    Prashant

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

    您好!

    为了以防万一、我在 SBL_OSPI 中使用了以下测试函数

    #define BOOTFLASH_BLOCK_SIZE (64U * 1024U)
    unsigned char bootloader_buffer[BOOTFLASH_BLOCK_SIZE] __attribute__((section(".bss.buf")));
    
    void test_func()
    {
        DebugP_log("/* Being testing */\r\n");
    
        Flash_Handle handle = Flash_getHandle(0);
    
        uint32_t base_offset = 0x100000;
    
        for(uint32_t i = 0; i < 25; i++) {
            Flash_read(handle, base_offset + i * BOOTFLASH_BLOCK_SIZE, bootloader_buffer, BOOTFLASH_BLOCK_SIZE);
        }
        
        DebugP_log("/* End testing */\r\n");
    }

    这些是成功完成的日志

    DMSC Firmware Version 9.2.8--v09.02.08 (Kool Koala)
    DMSC Firmware revision 0x9
    DMSC ABI revision 3.1
    
    /* Being testing */
    TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60120000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6012FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60130000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6013FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60140000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6014FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60150000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6015FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60160000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6016FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60170000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6017FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60180000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6018FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60190000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6019FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601A0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601AFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601B0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601BFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601C0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601CFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601D0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601DFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601E0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601EFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x601F0000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x601FFC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60200000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6020FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60210000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6021FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60220000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6022FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60230000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6023FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60240000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6024FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60250000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6025FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60260000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6026FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60270000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6027FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60280000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6028FC00, DST = 0x7007FC00, SIZE = 1024
    /* End testing */
    [BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH
    KPI_DATA: [BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz
    KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size  : 0 KB
    [BOOTLOADER_PROFILE] Cores present    :
    r5f0-0
    KPI_DATA: [BOOTLOADER PROFILE] SYSFW init                       :      12373us
    KPI_DATA: [BOOTLOADER PROFILE] System_init                      :     365267us
    KPI_DATA: [BOOTLOADER PROFILE] Drivers_open                     :        316us
    KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen                :      32361us
    KPI_DATA: [BOOTLOADER PROFILE] Sciclient Get Version            :       9990us
    KPI_DATA: [BOOTLOADER PROFILE] CPU load                         :     419895us
    KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken             :     840209us
    
    Image loading done, switching to application ...
    TR Response success for transfer : SRC = 0x60080700, DST = 0x7008000D, SIZE = 129024
    TR Response success for transfer : SRC = 0x6009FF00, DST = 0x7009F80D, SIZE = 17536
    TR Response success for transfer : SRC = 0x600A43A0, DST = 0x700B1241, SIZE = 4992
    Hello World!

    "TR Response Success"(TR 响应成功)日志是由于以下修补程序生成的

    diff --git a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    index b34df4d2..27c3a184 100644
    --- a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    +++ b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    @@ -245,6 +245,7 @@ static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* sr
             }
         }
     
    +    DebugP_log("TR Response success for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
         return status;
     }
     
    @@ -295,4 +296,4 @@ static int32_t OspiDma_udmaCopy(void* ospiDmaArgs, void* dst, void* src, uint32_
         }
     
         return status;
    -}
    \ No newline at end of file
    +}
    

    是否可以与您共享这样的测试功能以便发现问题? 我会试一下、看看它是否可重现。

    否则、您是否可以应用以下补丁以在发生故障的确切位置可靠地转储 SYSFW 日志

    diff --git a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    index b34df4d2..c0d0394c 100644
    --- a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    +++ b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
    @@ -182,6 +182,24 @@ static int32_t OspiDma_udmaClose(OSPI_DmaHandle handle, void* ospiDmaArgs)
     
     }
     
    +void dump_sysfw_logs()
    +{
    +    #define SYSFW_LOGS_BUFFER_ADDR 0x44043000
    +    #define SYSFW_LOGS_BUFFER_SIZE 0x0FE0
    +
    +    uint8_t* ptr = (uint8_t*)SYSFW_LOGS_BUFFER_ADDR;
    +
    +    DebugP_log("\r\n<<SYSFW_LOGS\r\n");
    +
    +    for(int32_t i = 0; i < SYSFW_LOGS_BUFFER_SIZE; i++)
    +    {
    +        DebugP_log("%c", *ptr);
    +        ptr++;
    +    }
    +
    +    DebugP_log("\r\nSYSFW_LOGS\r\n");
    +}
    +
     static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* src, uint16_t icnt[4])
     {
         int32_t status = UDMA_SOK;
    @@ -239,12 +257,14 @@ static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* sr
                 if(trRespStatus != CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE)
                 {
                     DebugP_log("TR Response failed for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
    +                dump_sysfw_logs();
                     DebugP_assert(FALSE);
                 }
                 break;
             }
         }
     
    +    DebugP_log("TR Response success for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
         return status;
     }
     
    @@ -295,4 +315,4 @@ static int32_t OspiDma_udmaCopy(void* ospiDmaArgs, void* dst, void* src, uint32_
         }
     
         return status;
    -}
    \ No newline at end of file
    +}
    

    使用此补丁、将从存储器缓冲区中读取 SYSFW 日志并将其转储到引导加载程序使用的同一 UART 中。

    此致、

    Prashant

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

    Jeff、您好!

    您是否可以尝试使用 大小值 64*1024-1、看看它是否有效?

     64KB 的最大值为65535。

    即使传递的数据超过64 KB、OSPI DMA 驱动程序也会进行两次传输、一次为64512传输、另一次为1024字节、这种情况下也不会遇到问题。 请查看 Prashant 日志。 相同的设置也同样适用。

    此致、

    Anil。

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

    感谢您提供的信息、我将尝试一些测试。

    这样做的一个不同之处是、我们将读取相同的目标存储器(我们一次散列64k、然后重复使用存储器)。

    您能否修改您的测试来执行该操作、看看它在我运行更多测试时是否有所不同? (我还在处理一些其他问题、因此可能需要一段时间才能做到这一点)

    谢谢

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我们所做的一件不同之事是我们正在读取相同的目标内存(我们一次散列64k、然后重复使用内存)。

    我实际上只是这样进行测试。 我使测试设置与您的相似。 这意味着、我将使用 Flash_Read 对位于您的同一位置(0x70000)的相同64K 目标缓冲区执行64K DMA 读取。 您也可能会看到日志。

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

    哦、抱歉、您是对的。 我快速浏览了 dst 地址、发现前2个地址不同、没有意识到它是在进行64512/1024拆分读取。

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

    我添加了你的 test_func()并在我们的散列检查之前调用它、我得到了以下信息

    /* Being testing */
    TR Response failed for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
    ASSERT: 0.689303s: ospi/v0/dma/udma/ospi_dma_udma.c:OspiDma_udmaUpdateSubmitTR:242: FALSE failed !!!

    然后,我添加了其他的调试信息,并把调用移动到 test_func()更早一点,我现在得到下面的,它不断重复

    /* Being testing */
    TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024
    /* Being testing */
    TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
    TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
    TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024
    

    我将我们的主代码与 examples\drivers\boot\sbl_ospi\am243x-evm\r5fss0-0_nortos\main.c 中的代码进行了比较、它们几乎匹配。

    您在 main 函数中的哪个位置对 test_func()进行了调用

    Example.syscfg 中是否有内容导致了该问题?

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

    Jeff、您好!

    您能否分享两个测试用例的图片?

    实际上、uDMA_drivers 打开的 API 将被称为 Drivers_open 函数。

    一旦,通道被初始化,然后 我们应该使用 DMA。

    因此、您的测试功能也应该在 Drivers_open API 之后调用。

    此致、

    Anil。

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

    我将调用 test_func()放在这2行之后

    drivers_open();
    Bootloader_profileAddProfilePoint ("Drivers_open");

    现在我看到的唯一输出是

    /*正在测试*/

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

    您的 example.syscfg 文件看起来是什么样的?

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

    Jeff、您好!

    我们使用了相同的系统 cfg 文件、该文件可从 SBL_OSPI 应用程序中获得。

    此致、

    Anil。

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

    我们目前的解决方案是使用 SDK 9.00构建引导加载程序、使用 SDK 9.02.01构建我们的主固件(到目前为止测试已在工作)

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

    Jeff、您好!

    因此、现在 SBL 09.00和09.02 MCU+SDK 应用程序正在运行。

    此外、 包含 09.02 MCU+SDK 应用程序的 SBL 09.02无法正常工作、并且您的 SBL 在 DMA 复制操作中抛出错误。

    这是我的理解。 如果我错了、请更正我。

    此致、

    Anil。

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

    看起来引导加载程序部分正常工作、但当我们进入主固件时、固件最终会挂起。 看起来它与 I2C 有关。 做更多调查。

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

    你好、Jeff、

    请告诉我您的代码在哪里悬挂?

    是在 主固件应用程序中的 I2C 时钟初始化期间进行的、哪个 I2C 类似于 I2 0或 I2C 1?

    如果您分享详细信息、我可以给出一些建议。

    此致、

    Anil。