Which codegen version is required for building code with TMS320F2803x Header Files and Flash Programming API?

Ruben Perez said:

Is there a specific codegen version required for building code with TMS320F2803x Flash Programming API? We have found that the default compiler in our CCS install (codegen v4.1.3) does not properly support the UNION and GROUP specifiers used in the header file .cmd files. We have confirmed that codegen v5.2.3 handles this ok, but now we just want to check if there is a specific codegen version required for using the F2803x header files and Flash API. Is this documented somewhere?

Hi Ruben,

Can you provide some details on how it didn't work?  I'm pretty sure GROUP and UNION have been available for quite a long time as we have been using them a long time.

More details will help us figure out what the problem is.

Ruben Perez said:

On a different note, we found an error on Page 17 of the document titled, "TMS320F2803x Piccolo Flash API". The first sentence refers to a Group section in a figure but the figure does not show a GROUP definition.

I will pass this along to the API owner.

Thank you for reporting it.

Regards

Lori

Lori Heustess said:

Can you provide some details on how it didn't work?  I'm pretty sure GROUP and UNION have been available for quite a long time as we have been using them a long time.

More details will help us figure out what the problem is.

We found that the v4.1.3 linker ignores the GROUP in the linker command entry below, and places all 5 datastructures at 0xD00. Switching to the newer codegen tools fixed this problem for us.

  UNION run = PIEVECT,                PAGE = 1
   {
      PieVectTableFile     : TYPE=DSECT
      GROUP
      {
         EmuKeyVar         : TYPE=DSECT
         EmuBModeVar       : TYPE=DSECT
         FlashCallbackVar  : TYPE=DSECT
         FlashScalingVar   : TYPE=DSECT
      }
   }

Ruben Perez said:

We found that the v4.1.3 linker ignores the GROUP in the linker command entry below, and places all 5 datastructures at 0xD00. Switching to the newer codegen tools fixed this problem for us.

Ruben,

Can you double check that it is compiler version 4.1.3.  Compiler version is different than code composer version.  There is also a code composer V4.1.3 and I want to make sure we are on the same track.   The compiler version will be indicated at the top of the .map file.

I have tried to reproduce the problem here without luck:

******************************************************************************
        TMS320C2000 COFF Linker PC v4.1.3                     
******************************************************************************
>> Linked Fri Sep 10 10:27:56 2010

OUTPUT FILE NAME:   <Example_Flash2803x_API.out>

........

........

PieVectTableFile
*          1    00000d00    00000000     UNINITIALIZED

EmuKeyVar
*          1    00000d00    00000001     UNINITIALIZED
                  00000d00    00000001     Example_Flash2803x_API.obj (EmuKeyVar)

EmuBModeVar
*          1    00000d01    00000001     UNINITIALIZED
                  00000d01    00000001     Example_Flash2803x_API.obj (EmuBModeVar)

FlashCallbackVar
*          1    00000d02    00000002     UNINITIALIZED
                  00000d02    00000002     Example_Flash2803x_API.obj (FlashCallbackVar)

FlashScalingVar
*          1    00000d04    00000002     UNINITIALIZED
                  00000d04    00000002     Example_Flash2803x_API.obj (FlashScalingVar)

Lori Heustess said:

Can you double check that it is compiler version 4.1.3.  Compiler version is different than code composer version.  There is also a code composer V4.1.3 and I want to make sure we are on the same track.   The compiler version will be indicated at the top of the .map file.

I have tried to reproduce the problem here without luck:

Lori,

Yes I confirm that it is codegen v4.1.3 not CCS. The customer is using CCS3.3 for this project. I'm attaching the linker map files generated by linker versions 4.1.3 and 5.2.3 for this. The only thing that was changed between these two builds was the codegen version in CCS3.3 component manager. Notice that the v5.2.3 linker correctly links the structures starting at line 88 of the file "Wheel Detection_523.map", while the v4.1.3 linker incorrectly links them all at 0xD00 starting on line 351 of file "Wheel Detection_413.map".

Ruben

Ruben Perez said:

Yes I confirm that it is codegen v4.1.3 not CCS. The customer is using CCS3.3 for this project. I'm attaching the linker map files generated by linker versions 4.1.3 and 5.2.3 for this. The only thing that was changed between these two builds was the codegen version in CCS3.3 component manager. Notice that the v5.2.3 linker correctly links the structures starting at line 88 of the file "Wheel Detection_523.map", while the v4.1.3 linker incorrectly links them all at 0xD00 starting on line 351 of file "Wheel Detection_413.map".

Ruben,

There must be something with this project or linker file that is confusing codegen 4.1.3.  I am still not able to reproduce it using the simple example that comes with the flash API.  I rebuilt using CCS 3.3 and Codegen 4.1.3 just to see and came up with the attached .map file.

I am going to move this to the compiler forum in case the experts there have seen something similar.

-Lori

Lori Heustess said:

There must be something with this project or linker file that is confusing codegen 4.1.3.  I am still not able to reproduce it using the simple example that comes with the flash API.  I rebuilt using CCS 3.3 and Codegen 4.1.3 just to see and came up with the attached .map file.

One difference is that our project uses DSPBIOS while the API example does not.

I don't understand why DSECT is being used here.  

Ruben Perez said:

  UNION run = PIEVECT,                PAGE = 1
   {
      PieVectTableFile     : TYPE=DSECT
      GROUP
      {
         EmuKeyVar         : TYPE=DSECT
         EmuBModeVar       : TYPE=DSECT
         FlashCallbackVar  : TYPE=DSECT
         FlashScalingVar   : TYPE=DSECT
      }
   }

That doesn't make sense to me.  Here is some info on section types in the linker, including DSECT http://www-k.ext.ti.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=32,E=0000000000018435053,K=2696,Sxi=0,Case=obj(52185)

Whatever is going on here, I suspect there is a different and better way to do it.

Thanks and regards,

-George

Georgem said:

I don't understand why DSECT is being used here.  

  UNION run = PIEVECT,                PAGE = 1
   {
      PieVectTableFile     : TYPE=DSECT
      GROUP
      {
         EmuKeyVar         : TYPE=DSECT
         EmuBModeVar       : TYPE=DSECT
         FlashCallbackVar  : TYPE=DSECT
         FlashScalingVar   : TYPE=DSECT
      }
   }

That doesn't make sense to me.  Here is some info on section types in the linker, including DSECT http://www-k.ext.ti.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=32,E=0000000000018435053,K=2696,Sxi=0,Case=obj(52185)

Whatever is going on here, I suspect there is a different and better way to do it.

[/quote]

George,

This usage of DSECT is part of a linker command file that comes with the standard header file product from the C2000 product team. I believe this is used to avoid linker erros caused by the fact that BIOS links the vectors to this address range. The purpose of the UNION is to create symbolic references for the headerfile structures, but these don't actually need to be loaded there.

Ruben

Ruben,

I think George has spotted the problem.  I didn't notice the DSECT before - this also tells the tools the variable doesn't take up any space.  I believe this is why all the variables in the GROUP are being collapsed into one address.  My apologies for this not being caught sooner by the apps team.

George,

Here is what we are trying to do:  The PieVectTableFile is normally defined in all of our projects - it is a structure that is mapped over the interrupt vector table for easy access.  The variables in the GROUP are used by the boot ROM so they have to be in a particular memory location - this happens to be at the start of the interrupt vector table (these were previously reserved locations).   The interrupt vector table is just RAM so we decided to use these reserved locations for these variables.

In a non-bios case PieVectTableFile is not DSECT.    In a BIOS case we make it DSECT because the bios .cmd file will create its own vector table strct.

The difficulty is the BIOS has one command file and we need to create a union in another command file. 

Do you have any thoughts on how to do this properly?

-Lori

Ruben,

A very brute force, crude workaround would be to create pointers to the variables in GROUP using the address itself.  I don't like suggesting the use of hard coded addresses but in this case it would get them up and going again and these addresses are fixed in the boot ROM code so they will not move around. 

Something like

#define MYEMUVARKEY  (uint16 *)0xD00;

etc.

-Lori

Lori Heustess said:

A very brute force, crude workaround would be to create pointers to the variables in GROUP using the address itself.  I don't like suggesting the use of hard coded addresses but in this case it would get them up and going again and these addresses are fixed in the boot ROM code so they will not move around. 

Something like

#define MYEMUVARKEY  (uint16 *)0xD00;

Lori,

Thanks for the suggestion. I also want to point out again that, whether right or wrong, the v5.2.x codegen tools produce teh desired effect without any changes to the linker command files. Is there any problem with just using that?

Ruben

Ruben Perez said:

Thanks for the suggestion. I also want to point out again that, whether right or wrong, the v5.2.x codegen tools produce teh desired effect without any changes to the linker command files. Is there any problem with just using that?

Ruben,

I'd still like to hear the input from the codegen team.  Unfortunately it sounds like 5.2.x may  be the one not handling this correctly as DSECT should not allocate any space.

-Lori 

Lori Heustess said:

I'd still like to hear the input from the codegen team.  Unfortunately it sounds like 5.2.x may  be the one not handling this correctly as DSECT should not allocate any space.

Lori,

Me too. To me it seems that 5.2.x handles it correctly. When I tested this with DSECT I see that there is no memory used (hence it avoids the linker collision with BIOS cmd) and the symbols aren't even added to the .out. However, any code that references the symbols in the DSECT variables correctly uses the intended addresses (0xD01, 0xD02, 0xD03...)

Ruben

Ruben Perez said:

Me too. To me it seems that 5.2.x handles it correctly. When I tested this with DSECT I see that there is no memory used (hence it avoids the linker collision with BIOS cmd) and the symbols aren't even added to the .out. However, any code that references the symbols in the DSECT variables correctly uses the intended addresses (0xD01, 0xD02, 0xD03...)

Ruben,

George and I discussed this.  I did not correctly understand DSECT.   The new tools are behaving as expected.  However George pointed out that the proper syntax should have the DSECT only on the outer element.   Neither the old tools are new are catching this.

Can you try removing the DSECT statements in RED and adding the one in BLUE to see if it makes a difference?   I'll make sure the syntax is corrected in the next header release.

Ruben Perez said:

  UNION run = PIEVECT,    TYPE=DSECT,    PAGE = 1
   {
      PieVectTableFile     : TYPE=DSECT
      GROUP
      {
         EmuKeyVar         : TYPE=DSECT
         EmuBModeVar       : TYPE=DSECT
         FlashCallbackVar  : TYPE=DSECT
         FlashScalingVar   : TYPE=DSECT
      }
   }

Regards,

Lori

Lori,

I just tested this and it looks ok. The syntax below produces the correct results with codegen v5.2.3 (see attached mapfile), but causes a linker error with codegen v4.1.3.

  UNION run = PIEVECT, TYPE=DSECT,      PAGE = 1
   {
      PieVectTableFile   
      GROUP
      {
         EmuKeyVar        
         EmuBModeVar      
         FlashCallbackVar 
         FlashScalingVar  
      }
   }

Ruben

Ruben Perez said:

The syntax below produces the correct results with codegen v5.2.3 (see attached mapfile), but causes a linker error with codegen v4.1.3.

That is probably a bug in v4.1.3.  Since it is fixed in later versions, it is no longer critical.  

Thanks and regards,

-George