Code generation issue porting to v4.2.2 (tools 4.3.8)

I have an issue porting production code from an older version of CCS (2.3) to v4.2.2 (cgt 4.3.8).

We have a state machine defined such that each state in the machine is an array of actions, where each action is a structure containing a triggering event, a service routine

and the next state to transition to.

typedef uint16 event_t;

typedef void (*event_service_t) (void);

typedef const struct state_action_s {

                event_t event;

                const struct state_action_s *next_state;

                event_service_t event_service;

} state_action_t, *state_t;

#pragma DATA_SECTION(om_startup,".sect_state");

 static state_action_t om_startup [] = {

                { 0x444 + 0x6000 + 0x1000, om_idle, l_om_startup },

{ 0x000, 0L, 0L } };

#pragma DATA_SECTION(om_idle,".sect_state");

 static state_action_t om_idle [] = {

                { 0x44a + 0x6000, 0L, esr_om_tick },

                { 0x44c + 0x6000, om_dm_connecting, e_om_dm_connecting },

                { 0x444 + 0x6000 + 0x1000, 0L, e_om_idle },

{ 0x000, 0L, 0L } };

The generated code is:

TMS320C55x Assembler PC v4.3.8 Sat Jul 30 14:45:38 2011

Tools Copyright (c) 1996-2010 Texas Instruments Incorporated

..\work\omc\monitor.asm                                              PAGE    1

    1233              ; Temporary Registers Used: None

       1              ;*******************************************************************************

       2              ;* TMS320C55x C/C++ Codegen                                          PC v4.3.8 *

       3              ;* Date/Time created: Sat Jul 30 14:45:36 2011                                 *

       4              ;*******************************************************************************

       5                      .compiler_opts --hll_source=on --mem_model:code=flat --mem_model:data=large --quiet --silicon_core_2_

       6                      .mmregs

       7                      .cpl_on

       8                      .arms_on

       9                      .c54cm_off

      10                      .asg AR6, FP

      11                      .asg XAR6, XFP

      12                      .asg DPH, MDP

      13                      .model call=c55_std

      14                      .model mem=large

      15                      .noremark 5684  ; code avoids SE CPU_116 indirect write

      16                      .noremark 5002  ; code respects overwrite rules

      17              ;*******************************************************************************

      18              ;* GLOBAL FILE PARAMETERS                                                      *

      19              ;*                                                                             *

      20              ;*   Architecture       : TMS320C55x                                           *

      21              ;*   Optimizing for     : Speed                                                *

      22              ;*   Memory             : Large Model (23-Bit Data Pointers)                   *

      23              ;*   Calls              : Normal Library ASM calls                             *

      24              ;*   Debug Info         : No Debug Info                                        *

      25              ;*******************************************************************************

      26 000000               .sect   ".sect_state"

      27                      .align  2

      28 000000       _om_startup:

      29 000000 7444          .field          29764,16                        ; _om_startup[0]._event @ 0

      30 000001               .space  16

      31 000002 0000+         .field          _om_idle,32             ; _om_startup[0]._next_state @ 32

         000003 000C

      32 000004 0000'         .field          _l_om_startup,32                ; _om_startup[0]._event_service @ 64

         000005 0042

      33 000006 0000          .field          0,16                    ; _om_startup[1]._event @ 96

      34 000007               .space  16

      35 000008 0000          .field          0,32                    ; _om_startup[1]._next_state @ 128

         000009 0000

      36 00000a 0000          .field          0,32                    ; _om_startup[1]._event_service @ 160

         00000b 0000

      37             

      38 00000c               .sect   ".sect_state"

      39                      .align  2

      40 00000c       _om_idle:

      41 00000c 644A          .field          25674,16                        ; _om_idle[0]._event @ 0

      42 00000d               .space  16

      43 00000e 0000          .field          0,32                    ; _om_idle[0]._next_state @ 32

         00000f 0000

      44 000010 0000'         .field          _esr_om_tick,32         ; _om_idle[0]._event_service @ 64

         000011 0220

      45 000012 644C          .field          25676,16                        ; _om_idle[1]._event @ 96

      46 000013               .space  16

      47 000014 0000+         .field          _om_dm_connecting,32            ; _om_idle[1]._next_state @ 128

         000015 0024

When the linker links the code, the address that is added to the word offset (000C on line 31) is incorrectly

a program memory address, not a data address.  This only happens if the state is a local state. If it is

external to the file, the result will be correctly a word offset from a word address.

Dave Satterlee

PS it should not be so difficult to get text into a browser.  I tried multiple browsers and editors to get something that would paste into the window, and actually be there when the post happened.  I was not using word.

Dave,

Can you provide a complete cutdown test case that can be used to reproduce this issue? A CCS project is fine. We would need the complete list of build options used and any details that would help us reproduce and understand the issue.

0654.x.zip

I have tried putting up a zip of the project.  The only option I had to change was large memory model.  To reproduce, build the code and look at the address for om_idle in the array om_startup (on line 31).  If your build comes out the same as mine - om_startup will be at 0x440000 dm and om_idle will be at 0x44000c dm, but the address in the array will be 0x88000c, which is incorrect.  If you remove the #pragma at line 34, so that om_idle is not explicitly placed into sect_state, then the address will change to the proper address.

In addition to this, could someone point me to the latest documentation for these code generation tools?  I have searched the CD, the install, the web and I must be being foolish, but I cannot seem to find anything recent, particularly the compiler and linker manual for ccs.4.2.2

Dave

Dave,

Thanks for providing the test case. I entered a bug report for it, the tracking # is SDSCM00041294. It has been assigned to the compiler team for further analysis and when there is an update on the status the bug report will be updated. You can track the status of the bug by going to the SDOWP link in my signature and entering the bug # in the "Find Record ID" field.

Dave Satterlee said:

In addition to this, could someone point me to the latest documentation for these code generation tools?

The compiler and linker manuals for the C55x have not been updated in a while. This wiki page has links to all the compiler/linker manuals (for other processor families as well) and some of the other ones have been updated more recently, so some features added in the toolset may be better documented in some of the other docs:
http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals

The cgtools releases also come with README.txt/LINKER_README.txt files that documents new features in that specific release.

I believe this bug is the same as SDSCM00040436.

Note the possible workaround for 40436.  If the current bug is the same then you could workaround it by having om_idle and om_startup be in different data sections.  (Not sure if that would be OK within your application.)