TMS320F28374D: File Links

David,

It is part of C2000ware installation, and is located at:

C:/ti/c2000/C2000Ware_3_03_00_00/device_support/f2837xd/headers/cmd/F2837xD_Headers_nonBIOS_cpu1.cmd

I had tried this before, and this is what I get......

So I assume it is also looking somewhere else for this file, just not sure where the path is being set.

     Thanks

David,

The picture did not came through. If you open project setting - Linker option, you should see the linker command. Here is the screen-shot from one of my project.

Thanks Santosh,

Is this where the path is set or just a reporting dialogue? The box title is "Summary of flags set:" so it is a little misleading.

If I delete this portion will it only look in the project directory for the *.cmd files? And does this also apply to the other paths? I would like to have all the necessary files in the project directory for portability.

        Thanks again,

              Dave

David,

The linker setting, you can set the Linker Include File (upper-pane) and Linker file-path (bottom pane).  In the summary, it displays all the linker include-path (just for review)

Yes, if you delete the cmd file from linker include file, then it expects .cmd file in the local folder. It will be true for all files.

We're getting closer Santosh.

Had to leave libc.a and the path (will figure those out later), but no I get these errors

David,

The picture did not came through. Can you try again saving png file or copy the whole console log and save to a .txt file and attach again?

Sorry Santosh, I thought I had pasted them and they appeared to have been posted.

I have attached a Word file with them in it.

 Links.docx

David,

This is your customer project, or any example from C2000ware? Did you make any change in DCSMZ1 section. It size should be 0x22

  ROMPREFETCH           0005e608   00000002  00000002  00000000  RWIX
  DCSMZ1                0005f000   00000023  00000022  00000001  RWIX
  DCSMZ2                0005f040   00000023  00000022  00000001  RWIX

Thanks for looking at this Santosh,

I did not modify any of those variables. The .cmd files are not modified. It compiles fine when it is setup to use the path as I originally indicated. Again see the Word fileLinks2.docx

Any more thoughts on where I should look Santosh?

Any thoughts on where I should look next Santosh?

David,

Replying on behalf of Santosh, we are having some connectivity issues for alot of our team due to the weather in Texas causing power and internet disruptions.

The errors from the link look to be related to the project not finding the DCSM register definitions.  There are two files that the pjt should find for this.  The overall path is here C:\ti\c2000\C2000Ware_3_01_00_00\device_support\f2837xd\headers

One file is F2837xD_GlobalVariableDefs that is in the \source sub dir.  I suspect this is being found since you would get many more errors than just the DCSM

The other is F2837xD_dcsm.h that is in the \include sub dir.  This has the register info associated with the dcsm regs.  Given the issues I might include both the paths(higher and specific).

I think this has to do with how CCS native creates a user copy of an imported project inside your windows User path.  This is to avoid changing the root files as you customize our examples but can give some relative path headaches that you are seeing.

I'm going to follow up with some others if we have some known best practices to avoid these issues in general.

Best,

Matthew

Thanks Matthew,

I highly suspect I am missing something obvious.

When I include

F2837xD_Headers_nonBIOS_cpu1.cmd in the include file (and exclude the copy in the project), it builds fine.

When I have nothing in the include file section, and enable the

F2837xD_Headers_nonBIOS_cpu1.cmd to be built from the project folder, I get errors

see Links3.docx

David,

I'm going to pull in some additional folks to confirm where/how the header.cmd file is getting added to the project, and one way vs the other as you have shown in the above attachment.

Below is what I have in an imported project(spi_ex_loopback) in the include dialogue, and this file doesn't show up explicitly in the project contents and this compiles correctly.  I suspect inside the package libs there must be an internal include for the linker file in question.  I'm still not sure why only the DCSM flagged an issue though.

Hi David ,

Is this the only linker cmd file (F2837xD_Headers_nonBIOS_cpu1.cmd) that you are including in the project? this linker cmd is used only for allocating the sections for the module registers. There has to be one more linker cmd file that defines sections for your code (.bss, .text, .stack and so on). See attached snapshot.

Best Regards

Siddharth

Thanks Siddharth,

The 2837xD_FLASH_Ink_cpu1.cmd is in the project directory. It was renamed since there were some modifications to it.

Let me know if the clip does not show up

Hi David ,

The clip is not showing up. Can you repost it again?

Are you facing this problem only with this project? If you import any other project , do you see the same issue?

Best Regards

Siddharth

Sorry Siddarth, I have attached a Word file that seems to work.

It is unclear whether or not this problem is unique to this project. I have successfully used a local .cmd file before, but not using the F2837xD_Headers_nonBIOS_cpu1.cmd in addition

Links4.docx

Hi David

I am still not sure what is causing this issue.

Is there any difference between the linker command files (F2837xD_Headers_nonBIOS_cpu1.cmd) - the one in the project directory and the one in the included path/search path.  I tried the same thing with an existing CCS project in C2000Ware - removing the linker command files from the project options and copying them into the project directory. The project builds fine for me even though the linker command files are present in the project directory. 

Best Regards

Siddharth

Thanks for your time Siddharth,

I went back through the Linker File/Path and removed everything that did not make a difference. I was left with 2 paths, one I believe is needed for the libc.a file. I looked in the remaining two paths for the F2837xD_Headers_nonBIOS_cpu1.cmd file and did not find any. So I assume the path is set somewhere else, maybe in the general include files. Is this possible? I have included the 2 scenarios of what works and what doesn't

           Thanks again

               Dave

Links5.docx

Hi Dave,

In the second scenario, what happens if you remove the ""${INSTALLROOT_F2837XD}/F2837xD_headers/cmd" from the project settings?

I don't think so the general include paths will include the cmd file.

Best Regards

Siddharth

We then get the following errors Siddarth. Oddly enough, if F2837xD_Headers_nonBIOS_cpu1.cmd is excluded from the build, we only get about 100 warnings, no errors.

 Hi Dave,

In the second scenario, do you have the linker command file "F2837xD_Headers_nonBIOS_cpu1.cmd" file available both in the include path "{INSTALLROOT_F2837XD}/F2837xD_headers/cmd" as well as in the project directory.

If so, can you remove it from the linker command from the include path and check if it resolves the issue.

Best Regards

Siddharth

Siddharth,

I think I have found the problem. The F2837xD_Headers_nonBIOS_cpu1.cmd file that was in the project folder was way different than the one I finally located in C:\ti\controlSUITE\device_support\F2837xD\v210\F2837xD_headers\cmd . When I copied the one from v210 into the project folder it built just fine. One of the big problems was trying to figure out the path that the CCS was accessing. The path that shows up when you mouse over the link in the "File Search Path" dialogue seems to go much deeper than where the *.cmd file is. I just started backing up from that until I found it

        Thanks for your help,

                Dave

As some more info, the C2000Ware version of F2837xD_Headers_nonBIOS_cpu1.cmd is different from the ControlSUITE version. The more recent version in C2000Ware did not work in my project. I have not tried using all the C2000Ware support files in my project to see if that would work. That would be quite an undertaking at this point.

       Thanks again for your time and help,

                Dave