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.

[参考译文] CCS11无法从调试器加载 F021闪存 API

Guru**** 665180 points
Other Parts Discussed in Thread: UNIFLASH, SEGGER, TMS570LS3137, RM48L952, HALCOGEN, TMS570LS0432, LAUNCHXL-TMS57004, RM42L432, LAUNCHXL-RM42
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger

器件型号:TMS570LS3137
主题中讨论的其他器件:UNIFLASHSEGGERRM48L952HALCOGENTMS570LS0432LAUNCHXL-TMS57004RM42L432LAUNCHXL-RM42

我们有一个 Hercules 应用、该应用链接到 F021闪存 API 库以进行闪存编程。  使用 CCS 11调试器加载应用程序时、不会加载闪存 API 部分、但会加载应用程序的其余部分。  使用 Segger 工具、Uniflash 7或 CCS 10.4加载相同的应用程序时、不会重现此行为: 所有段均按预期加载。

环境:

 - MCU: TMS570LS3137

 -编程器: SEGGER J-Link Pro

 - IDE: Windows 和 Linux 上的 Code Composer Studio 11.0.0.00012 (在两者上复制)

重现步骤:

1.编写一个使用 F021闪存 API 的 Hercules 应用程序。  将闪存 API 配置为从闪存复制到 RAM 中。  我们将闪存 API 库与以下链接器脚本(摘录)链接在一起:

   flashAPI : fill = 0xFFFFFFFF // This guarantees that the holes will be filled with this value.
   {
     Fapi_UserDefinedFunctions.obj (.text)
     bl_flash.obj (.text)
     --library= ../../common/flash_lib/F021_API_CortexR4_BE.lib (.text)
     . += FLASH_API_LENGTH - .; // Aforementioned hole that will be filled (remaining flash in this section).
   } load = FLASH_API, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)

2.获取具有空闪存的 TMS570器件、或擦除之前使用的器件上的闪存。  空闪存可确保您检测到闪存 API 部分是否未加载。

3.使用 CCS 11调试器将应用程序加载到器件上。

使用调试器、观察为闪存 API 部分保留的存储器部分未编程(0xFF)。

当在同一 ELF 二进制文件上运行时、以下工具会根据需要加载闪存 API 部分:

Code Composer Studio 10.4.0.00006

Uniflash 7.0.0.3615

SEGGER J-Flash 7.56.d

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

    尊敬的 Jack:

    您可以共享链接器 cmd 文件吗?  

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

    我使用 GCC 9.2.1编译器进行了项目设置、并将具有闪存 API 的 RM48L952配置为从闪存复制到 RAM 中、GCC 链接器脚本包含:

      /* used by the startup to initialize flashAPI */
       _siflashAPI = LOADADDR(.flashAPI);
    
      .flashAPI :
      {
        . = ALIGN(4);
    
        _sflashAPI = .;         /* create a global symbol at data start */
        *Fapi_UserDefinedFunctions.o (.text*)
        *F021_API_CortexR4_LE_V3D16.lib:* (.text*)
    
        . = ALIGN(4);
        _eflashAPI = .;            /* define a global symbol at data end */
      } >RAM AT> FLASH_API

    如需了解相关信息、请访问 https://github.com/Chester-Gillon/E2E_example_projects/tree/master/RM48L952_GCC_FEE_read_write

    在 Ubuntu 18.04下使用 CCS 11.0.0.00012、我无法重复该问题。

    链接器映射文件显示了大小为0x888的闪存 API 部分 被放置在地址0x20的闪存上、SRAM 中的运行地址为0x8001500:

    .flashAPI       0x0000000008001500      0x888 load address 0x0000000000000020
                    0x0000000008001500                . = ALIGN (0x4)
                    0x0000000008001500                _sflashAPI = .
     *Fapi_UserDefinedFunctions.o(.text*)
     .text          0x0000000008001500        0x8 ./source/Fapi_UserDefinedFunctions.o
                    0x0000000008001500                Fapi_serviceWatchdogTimer
     *F021_API_CortexR4_LE_V3D16.lib:*(.text*)
     .text          0x0000000008001508        0x0 /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.obj)
     .text:Fapi_issueAsyncCommand
                    0x0000000008001508       0x2a /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.obj)
                    0x0000000008001508                Fapi_issueAsyncCommand
     .text          0x0000000008001532        0x0 /home/mr_halfword/ti/Hercules/F021 Flash API/02.01.01/F021_API_CortexR4_LE_V3D16.lib(Async.WithAddress.obj)
     *fill*         0x0000000008001532        0x2 
    <snip>
     .text:Fapi_isAddressEEPROM.__stub
                    0x0000000008001d80        0x8 linker stubs
                    0x0000000008001d88                . = ALIGN (0x4)
                    0x0000000008001d88                _eflashAPI = .
                    0x0000000008001d88                . = ALIGN (0x4)

    使用的调试探针是 XDS100v2。

    在 CCS 工程属性的 Debug -> Flash Settings 下勾选"Enable Verbose Output"、使 CCS 报告执行了哪些闪存操作。

    启动调试会话时、可以看到所有闪存扇区都被擦除、然后写入并验证"长度为0x00000888的闪存@地址0x00000020 "、这是 F021闪存 API 的加载地址:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
    CortexR4: Writing Flash @ Address 0x00000000 of Length 0x00000020
    CortexR4: Erasing Flash Bank 0, Sector 0
    CortexR4: Erasing Flash Bank 0, Sector 1
    CortexR4: Erasing Flash Bank 0, Sector 2
    CortexR4: Erasing Flash Bank 0, Sector 3
    CortexR4: Erasing Flash Bank 0, Sector 4
    CortexR4: Erasing Flash Bank 0, Sector 5
    CortexR4: Erasing Flash Bank 0, Sector 6
    CortexR4: Erasing Flash Bank 0, Sector 7
    CortexR4: Erasing Flash Bank 0, Sector 8
    CortexR4: Erasing Flash Bank 0, Sector 9
    CortexR4: Erasing Flash Bank 0, Sector 10
    CortexR4: Erasing Flash Bank 0, Sector 11
    CortexR4: Erasing Flash Bank 0, Sector 12
    CortexR4: Erasing Flash Bank 0, Sector 13
    CortexR4: Erasing Flash Bank 0, Sector 14
    CortexR4: Erasing Flash Bank 1, Sector 0
    CortexR4: Erasing Flash Bank 1, Sector 1
    CortexR4: Erasing Flash Bank 1, Sector 2
    CortexR4: Erasing Flash Bank 1, Sector 3
    CortexR4: Erasing Flash Bank 1, Sector 4
    CortexR4: Erasing Flash Bank 1, Sector 5
    CortexR4: Erasing Flash Bank 1, Sector 6
    CortexR4: Erasing Flash Bank 1, Sector 7
    CortexR4: Erasing Flash Bank 1, Sector 8
    CortexR4: Erasing Flash Bank 1, Sector 9
    CortexR4: Erasing Flash Bank 1, Sector 10
    CortexR4: Erasing Flash Bank 1, Sector 11
    CortexR4: Erasing Flash Bank 7, Sector 0
    CortexR4: Erasing Flash Bank 7, Sector 1
    CortexR4: Erasing Flash Bank 7, Sector 2
    CortexR4: Erasing Flash Bank 7, Sector 3
    CortexR4: Verifying Flash @ Address 0x00000000 of length 0x00000020
    CortexR4: Writing Flash @ Address 0x00000020 of Length 0x00000888
    CortexR4: Verifying Flash @ Address 0x00000020 of length 0x00000888
    CortexR4: Writing Flash @ Address 0x00001500 of Length 0x00007ff0
    CortexR4: Verifying Flash @ Address 0x00001500 of length 0x00007FF0
    CortexR4: Writing Flash @ Address 0x000094f0 of Length 0x00005608
    CortexR4: Verifying Flash @ Address 0x000094F0 of length 0x00005608
    CortexR4: Writing Flash @ Address 0x0000eaf8 of Length 0x00000444
    CortexR4: Verifying Flash @ Address 0x0000EAF8 of length 0x00000444
    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
    

    程序运行成功、并确认调试器中的步进被称为闪存 F021 API 函数、该函数已从闪存复制到 SRAM。

    将尝试通过更改为使用的 TI 编译器/调试探针/不同器件来查看触发器是什么来重新创建问题。

    [引用 userid="477448" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger "]使用 CCS 11调试器加载应用程序时,不加载闪存 API 部分,但加载应用程序的其余部分[/quot]

    在出现故障的情况下、以下内容可能有助于获取更多信息:

    a.启动调试会话时 CCS 控制台的输出、在 闪存设置中选择了"Enable Verbose Output"。 编辑:使用 J-Link 时不存在该选项。 对于 J-Link、请启用 J-Link 日志文件。 发现 CCS 目标配置文件中的"J-Link 日志文件路径"似乎被忽略。 而是使用  "启用 J-Link 日志文件"中描述的通用方法

    b. CCS 调试服务器日志。 过去、调试服务器日志显示了调试器如何确定要对 ELF 二进制文件中的哪些段进行编程。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="91588" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889865 #3889865"]将尝试通过更改为使用的 TI 编译器/调试探针/不同的器件来重新创建问题、以查看触发值。

    使用  了与上述相同的 RM48L952程序、但在 Windows 10下使用 CCS 11.0.0.00012并使用 Segger J-Link。

    在测试之前、由于 Segger 闪存编程器在闪存中的内容已经匹配时跳过闪存、因此使用 XDS100v2能够使用 CCS 闪存选项擦除然后空白检查器件。

    仍然无法重新创建故障。

    在 JLinkLogOverride.log 中可以看到:

    1.对 JLINK_WriteMem 的调用(0x00000020、0x888字节...) 它用于闪存 F021 API:

    T1B30 3103:984.384 JLINK_BeginDownload(Flags = 0x00000000)
    T1B30 3103:984.384 - 0.037ms
    T1B30 3103:984.384 JLINK_WriteMem(0x00000000, 0x20 Bytes, ...)
    T1B30 3103:984.384   Data:  A2 15 00 EA FE FF FF EA FE FF FF EA FE FF FF EA ...
    T1B30 3103:985.152   completely In flash
    T1B30 3103:985.152 - 0.588ms returns 0x20
    T1B30 3103:985.152 JLINK_ReadMem(0x00000000, 0x4 Bytes, ...)
    T1B30 3103:985.152    -- Read from flash cache (4 bytes @ 0x00000000)
    T1B30 3103:985.152   Data:  A2 15 00 EA
    T1B30 3103:985.152 - 0.052ms returns 0
    T1B30 3103:985.408 JLINK_WriteMem(0x00000020, 0x888 Bytes, ...)
    T1B30 3103:985.408   Data:  00 00 A0 E3 1E FF 2F E1 10 B5 04 46 10 2C 0B D0 ...
    T1B30 3103:985.408   completely In flash
    T1B30 3103:985.408 - 0.125ms returns 0x888
    T1B30 3103:985.664 JLINK_ReadMem(0x00000020, 0x4 Bytes, ...)
    T1B30 3103:985.664    -- Read from flash cache (4 bytes @ 0x00000020)
    T1B30 3103:985.664   Data:  00 00 A0 E3
    T1B30 3103:985.664 - 0.050ms returns 0
    T1B30 3103:985.920 JLINK_WriteMem(0x00001500, 0x7FF0 Bytes, ...)
    T1B30 3103:985.920   Data:  10 B5 42 F2 CC 14 C0 F6 00 04 23 78 63 B9 40 F2 ...
    T1B30 3103:985.920   completely In flash
    T1B30 3103:986.176 - 0.088ms returns 0x7FF0
    T1B30 3103:986.176 JLINK_ReadMem(0x00001500, 0x4 Bytes, ...)
    T1B30 3103:986.176    -- Read from flash cache (4 bytes @ 0x00001500)
    T1B30 3103:986.176   Data:  10 B5 42 F2
    T1B30 3103:986.176 - 0.050ms returns 0
    T1B30 3103:986.432 JLINK_WriteMem(0x000094F0, 0x5608 Bytes, ...)
    T1B30 3103:986.432   Data:  28 23 02 E3 00 28 40 E3 C8 30 A0 E3 93 2A 23 E0 ...
    T1B30 3103:986.432   completely In flash
    T1B30 3103:986.432 - 0.073ms returns 0x5608
    T1B30 3103:986.688 JLINK_ReadMem(0x000094F0, 0x4 Bytes, ...)
    T1B30 3103:986.688    -- Read from flash cache (4 bytes @ 0x000094F0)
    T1B30 3103:986.688   Data:  28 23 02 E3
    T1B30 3103:986.688 - 0.050ms returns 0
    T1B30 3103:986.688 JLINK_WriteMem(0x0000EAF8, 0x444 Bytes, ...)
    T1B30 3103:986.944   Data:  00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ...
    T1B30 3103:986.944   completely In flash
    T1B30 3103:986.944 - 0.054ms returns 0x444
    T1B30 3103:986.944 JLINK_EndDownload()

    2.正在擦除的闪存和编程的闪存:

    T1B30 3103:987.200   Old firmware which does not support pausing periodic actions during flash download
    T1B30 3103:987.200    -- --------------------------------------
    T1B30 3103:987.200   Flash bank @ 0x00000000: Default: L2 verify disabled because algorithm performs L1 verify
    T1B30 3103:987.200    -- Start of determining dirty areas in flash cache
    T1B30 3103:988.224    -- End of determining dirty areas
    T1B30 3103:988.224    -- Start of preparing flash programming
    T1B30 3103:988.224    -- Calculating RAM usage
    T1B30 3103:988.224    -- RAM usage = 11368 Bytes
    T1B30 3103:988.224    -- Preserving CPU registers
    T1B30 3103:998.720    -- Preparing memory
    T1B30 3103:998.720    -- Determining CPU clock frequency
    T1B30 3104:283.136    -- Preparing target
    T1B30 3104:283.136    -- Preserving target RAM temporarily used for programming
    T1B30 3104:452.096    -- Downloading RAMCode
    T1B30 3104:546.560    -- Checking target RAM
    T1B30 3104:573.952    -- CPU frequency = 15997 kHz
    T1B30 3104:573.952    -- End of preparing flash programming
    T1B30 3104:574.208   Looking for J-Link GUI Server exe at: C:\ti\ccs1100\ccs\ccs_base\DebugServer\drivers\JLinkGUIServer.exe
    T1B30 3104:574.464   Looking for J-Link GUI Server exe at: \JLinkGUIServer.exe
    T1B30 3104:874.752   Failed to connect to J-Link GUI Server.
    T1B30 3104:886.784    -- CPU is running at 15997 kHz.
    T1B30 3104:886.784    -- Start of comparing flash
    T1B30 3104:886.784    -- CRC check was estimated as fastest method
    T1B30 3104:887.040    -- Comparing range 0x0000 - 0xFFFF (2 Sectors, 64 KB), using single-block CRC calculation
    T1B30 3104:999.936    -- CRC does not match, checking individual sectors
    T1B30 3105:063.680    -- CRC does not match for sector 0
    T1B30 3105:127.936    -- CRC does not match for sector 1
    T1B30 3105:128.192    -- End of comparing flash
    T1B30 3105:128.192    -- Start of erasing sectors
    T1B30 3105:128.192    -- Erasing range 0x00000000 - 0x00007FFF (  1 Sector, 32 KB)
    T1B30 3105:143.296    -- Erasing range 0x00008000 - 0x0000FFFF (  1 Sector, 32 KB)
    T1B30 3105:158.144    -- End of erasing sectors
    T1B30 3105:158.144    -- Start of flash programming
    T1B30 3105:158.400    -- Programming range 0x00000000 - 0x00007FFF (  1 Sector, 32 KB)
    T1B30 3106:004.992    -- Programming range 0x00008000 - 0x0000FFFF (  1 Sector, 32 KB)
    T1B30 3106:851.328    -- End of flash programming
    T1B30 3106:851.328    -- 0x0000 - 0xFFFF (  2 Sectors, 64 KoB)
    T1B30 3106:851.584    -- Start of restoring
    T1B30 3106:851.584    -- Restoring RAMCode
    T1B30 3106:865.664    -- Restoring target memory
    T1B30 3107:019.776    -- Restore target
    T1B30 3107:019.776    -- Restore memory
    T1B30 3107:019.776    -- Restoring CPU registers
    T1B30 3107:020.032    -- End of restoring
    T1B30 3107:020.032    -- Bank 0 @ 0x00000000: 1 range affected (65536 bytes)
    T1B30 3107:020.032    -- Total: 3.031s (Prepare: 0.898s, Compare: 0.241s, Erase: 0.030s, Program & Verify: 1.693s, Restore: 0.168s)
    T1B30 3107:020.032    -- Program & Verify speed: 37 KB/s
    T1B30 3107:024.128 - 3037.203ms returns 65536 (0x10000)
    

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="477448" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger "- IDE: Windows 和 Linux 上的 Code Composer Studio 11.0.0.00012 (在两者均有转载)

    您能否确认 CCS 11.0中安装了哪个版本的 SEGGER J-Link?

    回顾 CCS  11.0.0.00012中 Windows 和 Linux 下的安装历史记录:

    • 首次安装 CCS 11时、SEGGER J-Link 的版本为 v6.44.0.b
    •  当 CCS 更新提示时、执行了对 SEGGER J-Link v7.52.4.0和 v7.56.2.0的后续更新

    对于上述测试、我在  CCS 中使用 SEGGER J-Link v7.56.2.0。

     您的 TMS570LS3137 MCU 是一款大端器件。

       在针对 DLL 的版本 V7.52c (2021-08-10)的 J-Link/ Flasher 软件和文档包的发行说明中、有:

    [引述]2.  大端字节序 Cortex-A 和 Cortex-R 器件闪存编程、固定。[/QUERP]

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="91588" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889882 #3889882"]您能否确认 CCS 11.0中安装了哪个版本的 SEGGER J-Link?

    com.segger.jlink.win64.feature.group 为7.56.2.0 (可能对应于7.56.b?)

    com.segger.jlink.drivers.win64.feature.group 为1.0.1.0

    我不认为我可以将完整的链接器命令文件上载到公共论坛、但我可以确认我在 LS31x 器件的 spna193 UART 引导加载程序示例中看到了相同的问题。  此链接器命令文件如下所示:

    --retain="*(.intvecs)"
    
    
    MEMORY
    {
        VECTORS    (X)   : origin=0x00000000 length=0x00000020
        FLASH_API  (RX)  : origin=0x00000020 length=0x000014E0
        FLASH0     (RX)  : origin=0x00001500 length=0x002FEB00   //LS31x and RM48 Flash size is 0x300000
        SRAM       (RW)  : origin=0x08002000 length=0x0002D000
        STACK      (RW)  : origin=0x08000000 length=0x00002000
    }
    SECTIONS
    {
       .intvecs : {} > VECTORS
       flashAPI :
       {
         Fapi_UserDefinedFunctions.obj (.text)
         bl_flash.obj (.text)
         --library= ..\..\..\lib\F021_API_CortexR4_BE.lib (.text)
       } load = FLASH_API, run = SRAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)
    
       .text  > FLASH0
       .const > FLASH0
       .cinit > FLASH0
       .pinit > FLASH0
       .data  > SRAM
       .bss   > SRAM
    }
    

    我稍后将要查看 Segger 版本说明。

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

    以下是 CCS DebugServer 日志中的一些有趣的内容:

    0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 0
    0x00008204 13215 4 CortexR4 OFS_DWARF I: Attempting to read program file.  Trying COFF format.
    0x00008204 13215 4 CortexR4 OFS_DWARF I: Invalid COFF magic number
    0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 6
    0x00008204 13215 4 CortexR4 OFS_DWARF I: Attempting to read program file.  Now trying ELF format.
    0x00008204 13215 4 CortexR4 OFS I: OFS error code being set to 0
    0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .intvecs
    0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 32, or 0x20
    0x00008204 13215 4 CortexR4 OFS D:   load location: 0x0
    0x00008204 13215 4 CortexR4 OFS D:   run location: 0x0
    0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
    0x00008204 13215 4 CortexR4 OFS D:   offset in file: 52 or 0x34
    0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
    0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 3880, or 0xf28
    0x00008204 13215 4 CortexR4 OFS D:   load location: 0x8002000     <------ Look here
    0x00008204 13215 4 CortexR4 OFS D:   run location: 0x8002000
    0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
    0x00008204 13215 4 CortexR4 OFS D:   offset in file: 84 or 0x54
    0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .text
    0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 12408, or 0x3078
    0x00008204 13215 4 CortexR4 OFS D:   load location: 0x1500
    0x00008204 13215 4 CortexR4 OFS D:   run location: 0x1500
    0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
    0x00008204 13215 4 CortexR4 OFS D:   offset in file: 3968 or 0xf80
    0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .const
    0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 1066, or 0x42a
    0x00008204 13215 4 CortexR4 OFS D:   load location: 0x4578
    0x00008204 13215 4 CortexR4 OFS D:   run location: 0x4578
    0x00008204 13215 4 CortexR4 OFS D:   memory page: 0
    0x00008204 13215 4 CortexR4 OFS D:   offset in file: 16376 or 0x3ff8
    0x00008204 13215 4 CortexR4 OFS D: OFS Section added:  name: .cinit
    0x00008204 13215 4 CortexR4 OFS D:   size in bytes: 64, or 0x40
    0x00008204 13215 4 CortexR4 OFS D:   load location: 0x49a8
    0x00008204 13215 4 CortexR4 OFS D:   run location: 0x49a8
    0x00008204 13216 4 CortexR4 OFS D:   memory page: 0
    0x00008204 13216 4 CortexR4 OFS D:   offset in file: 17448 or 0x4428
    0x00008204 13216 4 CortexR4 OFS D: OFS Section added:  name: .pinit
    0x00008204 13216 4 CortexR4 OFS D:   size in bytes: 0, or 0x0
    0x00008204 13216 4 CortexR4 OFS D:   load location: 0x0
    0x00008204 13216 4 CortexR4 OFS D:   run location: 0x0
    0x00008204 13216 4 CortexR4 OFS D:   memory page: 0
    
    ... more sections follow

    同时、相同二进制文件上的 armofd 可提供以下结果:

     Section Information
    
        id name                      load addr  run addr      size align alloc
        -- ----                      ---------  --------      ---- ----- -----
         0 (no name)                 0x00000000 0x00000000     0x0     0   N  
         1 .intvecs                  0x00000000 0x00000000    0x20     4   Y  
         2 flashAPI                  0x00000020 0x08002000   0xf28     4   Y  
         3 .text                     0x00001500 0x00001500  0x3078     4   Y  
         4 .const                    0x00004578 0x00004578   0x42a     4   Y  
         5 .cinit                    0x000049a8 0x000049a8    0x40     8   Y  
         6 .pinit                    0x00000000 0x00000000     0x0     1   N  
         7 .data                     0x08002f28 0x08002f28   0x431     4   Y  
         8 .bss                      0x0800335c 0x0800335c    0x94     4   Y  
         9 .TI.noinit                0x00000000 0x00000000     0x0     1   N  
        10 .TI.persistent            0x00000000 0x00000000     0x0     1   N  
        11 __llvm_prf_cnts           0x08002000 0x08002000     0x0     1   Y  
        12 .debug_info               0x00000000 0x00000000 0x1a029     1   N  
        13 .debug_line               0x00000000 0x00000000  0x3da1     1   N  
        14 .debug_frame              0x00000000 0x00000000   0xdc5     4   N  
        15 .debug_abbrev             0x00000000 0x00000000  0x2fcd     1   N  
        16 .debug_str                0x00000000 0x00000000  0x8553     1   N  
        17 .debug_aranges            0x00000000 0x00000000   0x7c8     1   N  
        18 .debug_pubnames           0x00000000 0x00000000  0x12da     1   N  
        19 .debug_pubtypes           0x00000000 0x00000000  0x1c6e     1   N  
        20 Veneer$$CMSE              0x00000000 0x00000000     0x0     1   N  
        21 .ARM.attributes           0x00000000 0x00000000    0x57     0   N  
        22 .symtab                   0x00000000 0x00000000  0x5fe0     0   N  
        23 .TI.section.flags         0x00000000 0x00000000    0x1e     0   N  
        24 .strtab                   0x00000000 0x00000000  0x1922     0   N  
        25 .shstrtab                 0x00000000 0x00000000   0x119     0   N  
    
    

    请注意 FlashAPI 段的加载地址存在差异。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="477448" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889913 #3889913"]请注意 FlashAPI 段的加载地址存在差异。

    同意  flashAPI 段的加载地址中的差异似乎是问题:

    1. armofd 报告加载地址 为0x00000020 (闪存)、运行地址 为0x08002000 (SRAM)、这是正确的
    2. CCS DebugServer 日志报告加载地址和运行地址均为 0x8002000 (SRAM)、这是不正确的、并可能解释为什么 flashAPI 部分未编程到闪存中。
    [引用 userid="477448" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889912 #3889912"]我稍后将需要查看 Segger 发行说明。

    鉴于您在 CCS DebugServer 日志中发现的加载地址存在差异、我认为 Segger 软件不是问题所在。 如果您查看 J-Link 日志文件、则会发现 CCS 11 DebugServer 要求 Segger 软件将 flashAPI 段写入其 SRAM 中的运行地址、而不是闪存中的加载地址。

    [引用 userid="477448" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889912 #3889912"]我认为我无法将完整的链接器命令文件上载到公共论坛,但我可以确认,我看到了与 LS31x 器件的 spna193 UART 引导加载程序示例相同的问题。

    希望 TI 能够使用适用于 LS31x 器件的 UART 引导加载程序示例重复该问题并进行调查。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="91588" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3889865 #3889865"]将尝试通过更改为使用的 TI 编译器/调试探针/不同的器件来重新创建问题、以查看触发值。

    我使用 HALCoGen 04.07.01为 TMS570LS0432创建了 example_TI_fee_Write_Read.c 示例、并编辑了 sys_link.cmd 链接器命令文件、以设置闪存中加载地址和 RAM 中运行地址的闪存 API:

    /* USER CODE BEGIN (4) */
       flashAPI : fill = 0xFFFFFFFF // This guarantees that the holes will be filled with this value.
       {
         Fapi_UserDefinedFunctions.obj (.text)
         *F021_API_CortexR4_BE.lib (.text)
       } load = FLASH0, run = RAM, LOAD_START(api_load), RUN_START(api_run), SIZE(api_size)
    /* USER CODE END */

    链接器映射文件显示了闪存中的 flashAPI 段、其中闪存中的加载地址为0x0000d4e0、RAM 中的运行地址为0x08001500:

    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00000000    00000000    0000d4e0   0000d4e0    r-x
      00000000    00000000    00000020   00000020    r-x .intvecs
      00000020    00000020    0000d4c0   0000d4c0    r-x .text
    0000dc78    0000dc78    00003150   00003150    r-x
      0000dc78    0000dc78    00002ef0   00002ef0    r-x FEE_TEXT_SECTION
      00010b68    00010b68    00000180   00000180    r-- .const
      00010ce8    00010ce8    000000a0   000000a0    r-- FEE_CONST_SECTION
      00010d88    00010d88    00000040   00000040    r-- .cinit
    08001500    0000d4e0    00000798   00000798    r-x
      08001500    0000d4e0    00000798   00000798    r-x flashAPI
    08001c98    08001c98    00000208   00000000    rw-
      08001c98    08001c98    00000131   00000000    rw- FEE_DATA_SECTION
      08001dcc    08001dcc    0000006e   00000000    rw- .data
      08001e3a    08001e3a    00000066   00000000    rw- .bss

    这是 使用板载 XDS100v2在 LAUNCHXL-TMS57004中运行的。

    在 Windows 10下使用 CCS 11.0.0.00012可能会重复此问题:

    1.在 CCS 属性的 Debug -> Flash settings 下勾选"Enable Verbose Output"。 启动调试会话时 CCS 刷写程序时的输出确实显示写入闪存、其中涵盖了 flashAPI 段的加载地址:

    CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0CortexR4: GEL Output: 	Memory Map Setup for Flash @ Address 0x0 due to System Reset
    CortexR4: Writing Flash @ Address 0x00000000 of Length 0x00007ff0
    CortexR4: Erasing Flash Bank 0, Sector 0
    CortexR4: Erasing Flash Bank 0, Sector 1
    CortexR4: Erasing Flash Bank 0, Sector 2
    CortexR4: Erasing Flash Bank 0, Sector 3
    CortexR4: Erasing Flash Bank 0, Sector 4
    CortexR4: Erasing Flash Bank 0, Sector 5
    CortexR4: Erasing Flash Bank 0, Sector 6
    CortexR4: Erasing Flash Bank 0, Sector 7
    CortexR4: Erasing Flash Bank 0, Sector 8
    CortexR4: Erasing Flash Bank 0, Sector 9
    CortexR4: Erasing Flash Bank 0, Sector 10
    CortexR4: Erasing Flash Bank 0, Sector 11
    CortexR4: Erasing Flash Bank 0, Sector 12
    CortexR4: Erasing Flash Bank 0, Sector 13
    CortexR4: Erasing Flash Bank 0, Sector 14
    CortexR4: Erasing Flash Bank 7, Sector 0
    CortexR4: Erasing Flash Bank 7, Sector 1
    CortexR4: Erasing Flash Bank 7, Sector 2
    CortexR4: Erasing Flash Bank 7, Sector 3
    CortexR4: Verifying Flash @ Address 0x00000000 of length 0x00004D00
    CortexR4: Verifying Flash @ Address 0x00004D00 of length 0x000032F0
    CortexR4: Writing Flash @ Address 0x00007ff0 of Length 0x000054f0
    CortexR4: Verifying Flash @ Address 0x00007FF0 of length 0x00004D00
    CortexR4: Verifying Flash @ Address 0x0000CCF0 of length 0x000007F0
    CortexR4: Writing Flash @ Address 0x0000dc78 of Length 0x00003150
    CortexR4: Verifying Flash @ Address 0x0000DC78 of length 0x00003150
    

    2.当程序在 main()的开头停止时,验证程序失败,原因如下:

    CortexR4: File Loader: Verification failed: Values at address 0x08001500 do not match Please verify target memory and memory map.

    3.如果尝试运行程序时出现未定义的指令异常、这是因为从闪存复制到 RAM 的 flashAPI 段包含所有0xff。

    4.在 CCS 调试服务器日志中可以看到以下 flashAPI 部分、该部分错误地将加载位置报告 为 RAM 中的0x8001500、而不是闪存中的0x0000d4e0:

    0x0000209C 13194 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
    0x0000209C 13194 4 CortexR4 OFS D:   size in bytes: 1944, or 0x798
    0x0000209C 13194 4 CortexR4 OFS D:   load location: 0x8001500
    0x0000209C 13194 4 CortexR4 OFS D:   run location: 0x8001500
    0x0000209C 13194 4 CortexR4 OFS D:   memory page: 0
    0x0000209C 13194 4 CortexR4 OFS D:   offset in file: 54548 or 0xd514

    以及:

    0x0000209C 13194 4 CortexR4 OFS D: Program Header contents @ index 1
    0x0000209C 13194 4 CortexR4 OFS I: p_type: 0x00000001
    0x0000209C 13194 4 CortexR4 OFS I: p_offset: 0x0000d514
    0x0000209C 13194 4 CortexR4 OFS I: p_vaddr: 0x08001500
    0x0000209C 13194 4 CortexR4 OFS I: p_paddr: 0x0000d4e0
    0x0000209C 13194 4 CortexR4 OFS I: p_filesz: 0x00000798
    0x0000209C 13194 4 CortexR4 OFS I: p_memsz: 0x00000798
    0x0000209C 13194 4 CortexR4 OFS I: p_flags: 0x00000005
    0x0000209C 13194 4 CortexR4 OFS I: p_align: 0x00000004
    0x0000209C 13194 4 CortexR4 OFS I: PT_LOAD: 
    0x0000209C 13194 4 CortexR4 OFS D: OFS LOAD Section added:  name: .text
    0x0000209C 13194 4 CortexR4 OFS D:   size in bytes: 1944, or 0x798
    0x0000209C 13194 4 CortexR4 OFS D:   load location: 0x8001500
    0x0000209C 13194 4 CortexR4 OFS D:   run location: 0x8001500
    0x0000209C 13194 4 CortexR4 OFS D:   memory page: 0
    0x0000209C 13194 4 CortexR4 OFS D:   offset in file: 54548 or 0xd514

    随附了使用的示例、debug_server.log 文件是由 CCS 11.0生成的

    e2e.ti.com/.../TMS570LS0432_5F00_TI_5F00_fee_5F00_read_5F00_write.zip

    在 Windows 10下使用 CCS 10.4.0.00006时、该示例工作正常。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="91588" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3897668 #3897668"]在 Windows 10下使用 CCS 11.0.0.00012可能会重复以下问题:

    也可以使用上述示例在 Linux 下使用 CCS 11.0.0.00012重复相同的故障。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="91588" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1051370/ccs11-fails-to-load-f021-flash-api-from-debugger/3897668 #3897668"]

    这是 使用板载 XDS100v2在 LAUNCHXL-TMS57004中运行的。

    在 Windows 10下使用 CCS 11.0.0.00012可能会重复此问题:

    [/报价]

      在 CCS 11.0中显示问题的 TMS570LS0432_TI_fee_read_write.zip 使用了 BE32 TMS570LS0432。

    创建了示例、以在附加项目中使用板载 XDS100v2在 LAUNCHXL-RM42中的 LE RM42L432上运行。

     在 RM42L432上运行的示例 在 CCS 11.0中未显示问题。 因此、CCS 11.1中无法正确读取 ELF 映像中的加载地址的问题可能仅在大端字节序器件中发生。

    对于 RM42L432、链接器映射文件的 flashAPI 部分具有以下内容:

    SEGMENT ALLOCATION MAP
    
    run origin  load origin   length   init length attrs members
    ----------  ----------- ---------- ----------- ----- -------
    00000000    00000000    0000d4d4   0000d4d4    r-x
      00000000    00000000    00000020   00000020    r-x .intvecs
      00000020    00000020    0000d4b4   0000d4b4    r-x .text
    0000dc74    0000dc74    00003100   00003100    r-x
      0000dc74    0000dc74    00002ee0   00002ee0    r-x FEE_TEXT_SECTION
      00010b54    00010b54    00000180   00000180    r-- .const
      00010cd4    00010cd4    000000a0   000000a0    r-- FEE_CONST_SECTION
    00010d78    00010d78    00000040   00000040    r--
      00010d78    00010d78    00000040   00000040    r-- .cinit
    08001500    0000d4d4    000007a0   000007a0    r-x
      08001500    0000d4d4    000007a0   000007a0    r-x flashAPI
    08001ca0    08001ca0    00000208   00000000    rw-
      08001ca0    08001ca0    00000131   00000000    rw- FEE_DATA_SECTION
      08001dd4    08001dd4    0000006e   00000000    rw- .data
      08001e42    08001e42    00000066   00000000    rw- .bss

    CCS 11.0 debug_server.log 针对 flashAPI 段显示以下内容,该段的加载位置错误地报告为 0x8001500:

    0x000004DC 11228 4 CortexR4 OFS D: OFS Section added:  name: flashAPI
    0x000004DC 11228 4 CortexR4 OFS D:   size in bytes: 1952, or 0x7a0
    0x000004DC 11228 4 CortexR4 OFS D:   load location: 0x8001500
    0x000004DC 11228 4 CortexR4 OFS D:   run location: 0x8001500
    0x000004DC 11228 4 CortexR4 OFS D:   memory page: 0
    0x000004DC 11228 4 CortexR4 OFS D:   offset in file: 54536 or 0xd508

    但是、debug_server.log 后面有以下内容、其中给出了正确的加载位置0x0000d4d4:

    0x000004DC 11230 4 CortexR4 OFS D: Program Header contents @ index 1
    0x000004DC 11230 4 CortexR4 OFS I: p_type: 0x00000001
    0x000004DC 11230 4 CortexR4 OFS I: p_offset: 0x0000d508
    0x000004DC 11230 4 CortexR4 OFS I: p_vaddr: 0x08001500
    0x000004DC 11230 4 CortexR4 OFS I: p_paddr: 0x0000d4d4
    0x000004DC 11230 4 CortexR4 OFS I: p_filesz: 0x000007a0
    0x000004DC 11230 4 CortexR4 OFS I: p_memsz: 0x000007a0
    0x000004DC 11230 4 CortexR4 OFS I: p_flags: 0x00000005
    0x000004DC 11230 4 CortexR4 OFS I: p_align: 0x00000004
    0x000004DC 11230 4 CortexR4 OFS I: PT_LOAD: 
    0x000004DC 11230 4 CortexR4 OFS D: OFS LOAD Section added:  name: .text
    0x000004DC 11230 4 CortexR4 OFS D:   size in bytes: 1952, or 0x7a0
    0x000004DC 11230 4 CortexR4 OFS D:   load location: 0xd4d4
    0x000004DC 11230 4 CortexR4 OFS D:   run location: 0x8001500
    0x000004DC 11230 4 CortexR4 OFS D:   memory page: 0
    0x000004DC 11230 4 CortexR4 OFS D:   offset in file: 54536 or 0xd508

    e2e.ti.com/.../RM42L432_5F00_TI_5F00_fee_5F00_read_5F00_write.zip

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

    感谢 Chester 提供了出色的测试案例。 我也可以重现此问题。  

    我为此提出了一个错误。 跟踪链接: https://sir.ext.ti.com/jira/browse/EXT_EP-10633

    有关如何解决该问题的详细信息、请参阅上述链接。

    谢谢

    Ki