[参考译文] TMS320F2800157-Q1：重建时链接器错误：dcsm.cmd 包含两次

admin

Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1585415/tms320f2800157-q1-linker-error-on-rebuild-dcsm-cmd-included-twice

器件型号： TMS320F2800157-Q1
Thread 中讨论的其他器件： C2000WARE、 SysConfig

我在使用 TI 编译器在 CCS 上构建 F2800157 目标时遇到了一个奇怪的问题、导致 dcsm.cmd 文件在链接器调用中被包含两次。

如果我清理并编译、或只是重新编译工程、没有链接错误：

[491]Building target: "hardware_c.out"
[492]Invoking: C2000 Linker
[493]"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla2 --float_support=fpu32 --tmu_support=tmu0 -Ooff --opt_for_speed=5 --fp_mode=relaxed --fp_reassoc=on --define=__TMS320C28XX__ --define=DEBUG --define=_FLASH --c11 --fp_single_precision_constant --printf_support=full --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi --parallel=8 -z -m"hardware_c.map" --heap_size=0x100 --stack_size=0x200 --warn_sections -i"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/lib" -i"C:/ti/c2000/C2000Ware_5_04_00_00" -i"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/include" -i"C:/Projects/my_project/hardware_c/debug/syscfg" --reread_libs --define=_FLASH --diag_wrap=off --display_error_number --xml_link_info="hardware_c_linkInfo.xml" --entry_point=code_start --rom_model -o "hardware_c.out" "./src/bsp/include/bsp/board.obj" "./src/bsp/include/bsp/device.obj" "./src/bsp/include/bsp/dcsm.obj" "./src/bsp/include/bsp/c2000ware_libraries.obj" "./f280015x_codestartbranch.obj" "./src/hal_impl/NTC.obj" "./src/hal_impl/analogInputs.obj" "./src/hal_impl/debugIO.obj" "./src/hal_impl/digital_io.obj" "./src/hal_impl/feedbackOutput.obj" "./src/hal_impl/gatedriver.obj" "./src/hal_impl/hal.obj" "./src/hal_impl/mcu.obj" "./src/hal_impl/power_up.obj" "./src/hal_impl/pwm_in.obj" "./src/hal_impl/tick_timer.obj" "C:/ti/c2000/C2000Ware_5_04_00_00/driverlib/f280015x/driverlib/ccs/Debug/driverlib.lib" "../linker_files/280015x_generic_flash_lnk.cmd" -l"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd" -llibc.a -llib_common.lib -llib_app.lib -llib_chip.lib
[494]<Linking>
[495]Finished building target: "hardware_c

但是、如果我在一行中编译两次工程、会收到以下（截断）链接器错误：

[115]Building target: "hardware_c.out"
[116]Invoking: C2000 Linker
[117]"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla2 --float_support=fpu32 --tmu_support=tmu0 -Ooff --opt_for_speed=5 --fp_mode=relaxed --fp_reassoc=on --define=__TMS320C28XX__ --define=DEBUG --define=_FLASH --c11 --fp_single_precision_constant --printf_support=full --diag_suppress=10063 --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi --parallel=8 -z -m"hardware_c.map" --heap_size=0x100 --stack_size=0x200 --warn_sections -i"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/lib" -i"C:/ti/c2000/C2000Ware_5_04_00_00" -i"C:/ti/ccs2020/ccs/tools/compiler/ti-cgt-c2000_22.6.2.LTS/include" -i"C:/Projects/my_project/hardware_c/debug/syscfg" --reread_libs --define=_FLASH --diag_wrap=off --display_error_number --xml_link_info="hardware_c_linkInfo.xml" --entry_point=code_start --rom_model -o "hardware_c.out" "./src/bsp/include/bsp/board.obj" "./src/bsp/include/bsp/device.obj" "./src/bsp/include/bsp/dcsm.obj" "./src/bsp/include/bsp/c2000ware_libraries.obj" "./f280015x_codestartbranch.obj" "./src/hal_impl/NTC.obj" "./src/hal_impl/analogInputs.obj" "./src/hal_impl/debugIO.obj" "./src/hal_impl/digital_io.obj" "./src/hal_impl/feedbackOutput.obj" "./src/hal_impl/gatedriver.obj" "./src/hal_impl/hal.obj" "./src/hal_impl/mcu.obj" "./src/hal_impl/power_up.obj" "./src/hal_impl/pwm_in.obj" "./src/hal_impl/tick_timer.obj" "C:/ti/c2000/C2000Ware_5_04_00_00/driverlib/f280015x/driverlib/ccs/Debug/driverlib.lib" "../linker_files/280015x_generic_flash_lnk.cmd" "../src/bsp/include/bsp/dcsm.cmd" -l"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd" -llibc.a -llib_common.lib -llib_app.lib -llib_chip.lib
[118]<Linking>
[119]"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd", line 19: error #10263: DCSM_OTP_Z1_LINKPOINTER memory range has already been specified
[120]"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd", line 19: error #10264: DCSM_OTP_Z1_LINKPOINTER memory range overlaps existing memory range DCSM_OTP_Z1_LINKPOINTER
...
[148]"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd", line 39: error #10264: DCSM_ZSEL_Z2_P0 memory range overlaps existing memory range DCSM_ZSEL_Z2_P0
[149]error #10010: errors encountered during linking; "hardware_c.out" not built

主要的区别是重建也突然包含"../src/bsp/include/bsp/dcsm.cmd",这显然是一个错误,因为同一个文件已经包含一次: -l"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd"

通过查看工程属性、我找不到任何看起来负责包含 dcsm.cmd 条目的位置。需要注意的是、syscfg 生成的文件位于“ c：/Projects/my_project/hardware_c src /bsp/include/bsp/ “、那么该路径可能是自动扫描的、并且添加了已知的文件吗？

我的假设是在下配置了自动扫描的位置 “Projects Properties“->"Build"->"C2000 Linker"->"File“ Linker"->"File Search“ Search Path"“ Path"</s>“ ““但是、除了我自己的库之外、我在该位置设置了以下文件集、其中没有一个文件可以控制其中的任何一个文件。

  将库文件或命令行文件作为输入 (--library,-l)：
   $｛INHERITED_LIBRARS｝
   $｛COM_TI_C2000WARE_libraries｝
   libc.a

例程

到库搜索路径 (--search_path、-i)：
   $｛INHERITED_LIBRARY_PATH｝
   $｛COM_TI_C2000WARE_LIBRARY_PATH｝
   $｛CG_TOOL_ROOT｝/lib
   $｛CG_TOOL_ROOT｝/包含
   $｛C2000WARE_ROOT｝
   $｛PROJECT_BUILD_DIR｝/syscfg

我尝试从编译中排除文件，这使得第二个编译成为可能，因为该条目从链接器调用行中忽略了 — 但此修复只会持续到发出清理命令为止。 dcsm.cmd "../src/bsp/include/bsp/dcsm.cmd":-(

发生什么事了？我如何确保同一个自动生成的文件不会（自动）包含两次？

8 个月前

0 admin 7 个月前

TI__Guru**** 2847390 points

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

您好：

我对延迟的答复表示歉意。这条线今天才引起我的注意。

是否可以获得可重现的测试案例？如果没有、也许只有项目文件夹内的三个.*项目元数据文件？如果您不想在此处发帖、可以通过私人 E2E 消息发送。

谢谢

0 admin 7 个月前

TI__Guru**** 2847390 points

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

尊敬的 Ki：

感谢您的答复。

我发送了一条私人消息、其中包含工程的 zip 文件、但不包含源文件和头文件。我相信你只需要添加一个包含 main() 实现的源文件来编译它。

请执行以下步骤以观察问题的实际情况：

测试 1 — 正常清洁+制造
1. 干净
2. Build — 观察链接器调用中仅指定一个 dcsm.cmd。
3. 重建所有内容（缓慢）
测试 2 — 构建后的正常构建
1. 编辑单个 c 或 h 文件。
2. Build — 观察链接器调用中指定了两个 dcsm.cmd。
3. 仅重建已更改的文件。(quick)、则链接器因范围重叠而失败。
测试 3 -构建后的正常构建 — 删除了 dcsm.cmd 文件。
1. 删除 BSP 文件夹中的“dcsm.cmd"文件“文件。
2. 编辑单个 c 或 h 文件。
3. Build — 观察链接器调用中仅指定一个 dcsm.cmd。
4. 重建已更改的文件。（以及整个 BSP（比完整的重建更快，但仍然很慢）。
测试 4 -构建后的正常构建 — 从构建中排除 dcsm.cmd 文件。
1. 在 BSP 文件夹中的“dcsm.cmd"文件“文件中选择“exclude from build“。
2. 编辑单个 c 或 h 文件。
3. Build — 观察链接器调用中仅指定一个 dcsm.cmd。
4. 仅重建已更改的文件。（快速-我在构建过程中一直期望的内容）

我当前运行的编译后步骤中有一个脚本、该脚本会删除 dcsm.cmd 文件 — 这并不完美，但它会节省我大量时间。

如果有句柄可执行此操作、我完全可以从端口构建中排除该文件？（我找不到关于它的任何信息）。

我也尝试添加一个对.project 文件执行 multiFilter、但这会使 CCS 在打开工程时挂起、因此我猜新的 CCS 中不再存在该选项。

<filteredResources>
  <filter>
    <id>1700000000001</id>
    <type>26</type>
    <matcher>
      <id>org.eclipse.ui.ide.multiFilter</id>
      <arguments>1.0-name-matches-false-false-dcsm.cmd</arguments>
    </matcher>
  </filter>
</filteredResources>

我期待着您的回答。

弗莱明

0 admin 7 个月前

TI__Guru**** 2847390 points

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

感谢您提供测试用例。这是非常有帮助的。

应注意的是、syscfg 生成的文件位于“ c：/Projects/my_project/hardware_c src /bsp/include/bsp/ “、那么路径可能是自动扫描的、并且添加了已知的文件？

该问题确实与 SysConfig 有关。问题是您将目录管理模式从默认的“自动“更改为“手动“、然后将自定义生成的输出目录更改为主项目文件夹 (.\bsp\include\bsps) 内的自定义文件夹。反过来、SysConfig 生成的所有文件都已自动添加到工程中（包括 dcsm.cmd）。现在问题是、SysConfig 已经在后台自动将任何生成的文件包含到构建中、而无需显式地将文件添加/引用到工程中。 dcsm.cmd 已在后台自动传递给链接器。然后、使用在工程文件夹中生成的 DSCM.cmd 文件、链接器将看到该文件并也会选择该文件。因此是双基准的原因。

使用“automatic"时“时、CCS 将在编译配置子文件夹中生成文件（例如工程中的“debug"）“）。编译配置子文件夹内的任何源文件都会从编译中自动排除、因此这是“automatic"默认“默认行为的原因。

如果要使用“手动“、则用户需要考虑此行为、并显式标记要排除的自定义文件夹或在工程文件夹之外生成文件。

至于：

如果我清理并编译工程、或者只是重新编译工程、没有链接错误：

清理重建会在编译之前删除该 BSP 文件夹的内容、然后生成的编译的 makefile 文件然后开始编译（在此步骤之后将生成生成生成的文件）。因此、这些 SysConfig 生成的文件不会成为构建的一部分。

我希望这有助于澄清正在发生的事情。

谢谢

0 admin 7 个月前

TI__Guru**** 2847390 points

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

感谢您的快速回答。

我已经知道这是发生的,但你的解释有助于充分理解它。

问题是、我们需要在源代码控制下实现由 SYSCFG 自动生成的文件、并且需要能够实现多个依赖于这些文件的目标、例如 debug、Release 和几种类型的测试等。因此我们不希望同一个文件有多个生成的副本。

我的下一个问题是、如何将 SYSCFG 输出其文件的文件夹标记为“用户文件“的一部分（因为没有更好的描述性字）-而且、这乍一看不应该是 SYSCFG 或 CCS 的自然行为？

此致、

弗莱明

0 admin 7 个月前

TI__Guru**** 2847390 points

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

那么我的下一个问题是、如何将 SYSCFG 输出其文件的文件夹标记为“用户文件“的一部分（因为缺少更好的描述性单词）

请参阅： https://software-dl.ti.com/ccs/esd/documents/users_guide_ccs/ccs_project-management.html#exclude-files-from-build

此外、这乍一看是否是 SYSCFG 或 CCS 的自然行为？

这是一个好问题。我只是和工程部门讨论了在选择“手动“时如何提高可用性。选择包含其他现有内容的文件夹时会发生什么情况。自动排除整个文件夹也会无意中排除这些文件。也许答案就是排除每个单独生成的文件。这是需要考虑的。

0 admin 7 个月前

TI__Guru**** 2847390 points

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

令我惊讶的是、可以排除包含 SYSCFG 生成文件的整个文件夹、但仍然可以构建项目。这对我来说很不自然。

如您所知、我尝试仅排除 dcsm.cmd

我原本以为如果我排除了一个文件、整个编译都会失败。

dcsm.cmd 文件也是特殊的，因为它是在编译期间创建的，并在清理过程中进行擦除 — 在我看来，它属于输出文件夹，因为它始终是重新生成的。

我对您的问题的看法是、如果在工程内部生成了 SYSCFG 输出文件夹中的文件、则不应自动添加、也不应自动排除。并且 SysGen 生成的文件不应被 Clean 删除、但在需要时始终覆盖。这意味着它应该跟踪文件而不是文件夹。

这将使我能够解决例如中的问题 board.c 、方法是排除该文件并将其替换为 board_fixed.c 。 SYSCFG 仍会生成 board.c、因此对于新版本的 C2000Ware、会生成新版本的 board.c、并且可以轻松进行切换。

我相信这会增加系统运作的透明度！

但谢谢 — 现在我将排除整个文件夹。

C2000™︎ 微控制器（参考译文帖）

C2000™︎ 微控制器（参考译文帖）(Read Only)

[参考译文] TMS320F2800157-Q1：重建时链接器错误：dcsm.cmd 包含两次