TMS320F2800157-Q1: Linker error on rebuild: dcsm.cmd included twice

Flemming Steffensen

Part Number: TMS320F2800157-Q1
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG

I have a strange problem building a F2800157 target on CCS with the TI compiler, whereby the dcsm.cmd file gets included twice in the linker invocation.

If I clean and build, or simply rebuild the project, I have no linking errors:

[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

But if I build the project twice in a row, I get the following (truncated) linker errors:

[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

The main difference is that the rebuild suddenly also includes "../src/bsp/include/bsp/dcsm.cmd", which is obviously an error as the same file is already included once: -l"C:/Projects/my_project/hardware_c/src/bsp/include/bsp/dcsm.cmd"

But looking through the project properties, I can't find any location that appear responsible for including either of the dcsm.cmd entries. It should be noted that the syscfg generated files are located at "C:/Projects/my_project/hardware_c/src/bsp/include/bsp/", so perhaps that path is auto-scanned and known files added?

It is my assumption that the auto-scanned locations are configured under Projects Properties -> Build -> C2000 Linker -> File Search Path, but aapart from my own libraries, I have the following set at that location, and none of them control either of the included files.

Include library file or commandline file as input (--library, -l):
${INHERITED_LIBRARIES}
${COM_TI_C2000WARE_LIBRARIES}
libc.a
<some private libs>

Add <dir> to library search path (--search_path, -i):
${INHERITED_LIBRARY_PATH}
${COM_TI_C2000WARE_LIBRARY_PATH}
${CG_TOOL_ROOT}/lib
${CG_TOOL_ROOT}/include
${C2000WARE_ROOT}
${PROJECT_BUILD_DIR}/syscfg
<some private libs folders>

I tried to exclude the dcsm.cmd file from the build, which made a second build possible, as the "../src/bsp/include/bsp/dcsm.cmd" entry did dissapear from the linker invocation line - but this fix only lasted till a clean was issued. :-(

So what is going on? And how can I make sure the same auto-generated file is not (automatically) included twice?

9 months ago

0 Ki 8 months ago

TI__Guru**** 484881 points

Hello,

My apologies for the delayed response. This thread was only brought to my attention today.

Would it be possible to obtain a reproducible test case? If not, perhaps just the three .*project metadata files inside the project folder? You can send via private E2E message if you do not want to post here.

Thanks

0 Flemming Steffensen 8 months ago in reply to Ki

Prodigy 140 points

Hi Ki,

Thank you for your reply.

I have send a private message with a zip file containing the project, but without source and header files. I believe you just need to add a source file with a main() implementation to have it compile.

Please perform the following steps in order to observe the problem in action:

Test 1 - normal clean + build
1. Clean
2. Build - observe only one dcsm.cmd is specified in the linker call.
3. Rebuilds everything (slow)
Test 2 - normal build after a build
1. Edit a single c or h file.
2. Build - observe two dcsm.cmd is specified in the linker call.
3. Rebuilds only changed file.(quick), then the linker fails with overlapping ranges.
Test 3 - normal build after a build - with deleted dcsm.cmd file.
1. Delete the "dcsm.cmd" file in the bsp folder.
2. Edit a single c or h file.
3. Build - observe only one dcsm.cmd is specified in the linker call.
4. Rebuilds the changed file.(and the entire BSP (quicker than a complete rebuild, but still slow.)
Test 4 - normal build after a build - with dcsm.cmd file excluded from build.
1. Select "Exclude from build" on the "dcsm.cmd" file in the bsp folder.
2. Edit a single c or h file.
3. Build - observe only one dcsm.cmd is specified in the linker call.
4. Rebuilds only the changed file.(quick - What I would always expect on a build)

I'm currently running with a script in the post-build step that deletes the dcsm.cmd file - it's not perfect, but it saves me a lot of time.

I would be perfectly fine with excluding the file from the port-build, if there are handles to do that? (I could not find any info about it).

I also tried to add a <filteredResources> multiFilter to the .project file, but this just make CCS hang when opening the project, so I guess this option no longer exist in the new 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>

I'm looking forward to your answer.

Flemming

0 Ki 8 months ago

TI__Guru**** 484881 points

Thank you for providing the test case. It was very helpful.

Flemming Steffensen said:
It should be noted that the syscfg generated files are located at "C:/Projects/my_project/hardware_c/src/bsp/include/bsp/", so perhaps that path is auto-scanned and known files added?

The issue is indeed related to SysConfig. The issue is that you changed the directory management mode to "manual" from the default "automatic" and then have your custom generated output directory to a custom folder inside the main project folder (.\bsp\include\bsp). This, in turn, had all the generated files from SysConfig auto-added to the project (including dcsm.cmd). Now the issue is that SysConfig will already auto-include any generated files to the build under the hood without the needs to explicitly add/reference the files to the project. So dcsm.cmd was already being auto-passed to the linker under the hood. Then with the dscm.cmd file generated inside the project folder, the linker will see that and pick it up also. Hence why the double reference.

When "automatic" is used, CCS will generate the files inside the build configuration subfolder (such as "debug" in your project). Any source files inside the build configuration subfolder are auto-excluded from the build hence why this is the default behavior of "automatic".

If "manual" is to be used, then the user will need to account for this behavior and either explicitly mark the custom folder to be excluded or generate the files outside the project folder.

As for:

Flemming Steffensen said:
If I clean and build, or simply rebuild the project, I have no linking errors:

A clean rebuild would delete the contents of that bsp folder before the build, then the makefiles for the build generated then the build would commence (generated files would then be generated after this step). Hence those SysConfig generated files would not be part of the build.

I hope this helps clarify what is happening.

Thanks

0 Flemming Steffensen 8 months ago in reply to Ki

Prodigy 140 points

Thank you for the quick answer.

I kind of already understood that this was happening, but your explanation helps fully understand it.

The thing is that we need to have the files that are auto-generated by the SysCfg under source control and we need to be able to have multiple targets that depend on those files, such as debug, release, and several types of test, etc. so we do not want to have multiple generated copies of the same files.

So my next question is, how can mark the folder that SysCfg output it's files to, as not part of the "user files" (for lack of a better descriptive word) - and also, shouldn't this be a natural behaviour of SysCfg or CCS in the first place?

Best regards,

Flemming

+1 Ki 8 months ago in reply to Flemming Steffensen

TI__Guru**** 484881 points

Flemming Steffensen said:
So my next question is, how can mark the folder that SysCfg output it's files to, as not part of the "user files" (for lack of a better descriptive word)

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

Flemming Steffensen said:
and also, shouldn't this be a natural behaviour of SysCfg or CCS in the first place?

It is a good question. I was just discussing with engineering about how to improve usability when "manual" is selected. What happens when a folder which has other existing content is selected. Auto-excluding that whole folder would inadvertently exclude those files also. Perhaps the answer is then just to exclude each individual generated file. It is something to consider.

0 Flemming Steffensen 8 months ago in reply to Ki

Prodigy 140 points

It surprises me that it's possible to exclude the whole folder containing SysCfg generated files, and still have the project build. This feels very unnatural for me.

As you know I tried to exclude just the dcsm.cmd

I had expected that the entire build would fail if I even excluded one file.

The dcsm.cmd file is also special, as it is created during build and erased during clean - in my opinion it belongs in the output folder as it's always regenerated.

My opinion on your question is that files in the SysCfg output folder, if generated inside the project, should not be auto-added and also not be auto-excluded. And SysGen generated files should not be deleted by clean, but always overwritten if needed. This means it should keep track on files and not the folder.

This would allow me to fix issues in for example board.c, by excluding that file and replacing it by board_fixed.c. SysCfg would still generate board.c, so with new versions of C2000Ware, new versions of board.c would be generated and be easily diff-able.

I believe this would add transparency to how the system works!

But thank you - for now I will exclude the whole folder.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F2800157-Q1: Linker error on rebuild: dcsm.cmd included twice