LAUNCHXL-F280049C: #pragma with linker --rom_model

So the #pragma DATA_SECTION() will only move data to RAM or Flash but not both, even with defined *.cmd sections. Hence RAM loaded compound variable using struct alias is being recognized but refuse to transfer the #define contents to the compound formed variable of alias variable named in a typedef struct. The data needs to be in Flash and RAM both. Getting the control data into Flash sectors via #pragma is easy but also copy it into RAM for fast ISR execution and HID modification remains an issue.

1st example: refuses transfer static voltage #defined value when function() compound variable resides asserts.  Oddly CCS editor (mouse hovering over the #define) shows data present via paused debug flash load. 

typedef struct }; My_Params myParams (inside the function)

myParams.dcBus_nominal_V = NOMINAL_DC_BUS_VOLTAGE_V;

2nd example: Only transfers the #defined value from same typedef struct variable name via pointer to the #define. Seemingly not indirect memory addressing or CPU access to read the data. It's shouldn't require CLA, right?

typedef struct }; My_Params myParams (not inside the function)

myParams->dcBus_nominal_V = NOMINAL_DC_BUS_VOLTAGE_V; 

f280049x_cpu_is_flash.cmd trial by error:

SECTIONS
{

.myvars.ramdata : LOAD = FLASHB1_SA,
RUN = RAMLS2_3,
ALIGN(4)

.myparams.ramdata : LOAD = FLASHB1_SA,
RUN = RAMLS2_3,
ALIGN(4)

}

SECTIONS
{

params_flashdata : > FLASH_BANK1_SEC12 /* FAPI control 4096 RW memory */
params_flashdata : > FLASH_BANK1_SEC13 /* FAPI control 4096 RW memory */

myvars_flashdata : > FLASH_BANK1_SEC14 /* FAPI control 4096 RW memory*/
myvars_flashdata : > FLASH_BANK1_SEC15 /* FAPI control 4096 RW memory */

.myparams.ramdata : > RAMLS2_3
.myvars.ramdata      : > RAMLS2_3

}

Genatco said:

Why does compiler issues warning "unrecognized pragma" (DUAL_STATE)

The DUAL_STATE pragma is only supported by the TI proprietary Arm compiler.  Even then, it is part of a method for changing CPU state (32-bit or 16-bit instructions) under the old TIABI.  All of these features are not supported in recent releases of the TI proprietary Arm compiler.  

Genatco said:

no linker -md linker command?

For the same reason DUAL_STATE is not supported.

Thanks and regards,

-George

I don't understand everything in your posts.  But it seems to be focused on this idea ...

Genatco said:

The data needs to be in Flash and RAM both.

That is not supported.  A section of data can load in one memory range (typically Flash) and execute from a different memory range (typically RAM).  But that's it.  No other method for managing the data is supported.  For instance, you cannot sometimes read from Flash, and then other times read from RAM.

Thanks and regards,

-George

Hi George,

George Mock said:

All of these features are not supported in recent releases of the TI proprietary Arm compiler.  

This is a C2000 MCU I'm referring to, not an ARM MCU. Also listed in the C2000 compiler guide section 5.11 latest compiler LTS versions. It was read to support dual state memory functions. Why mention compiler optimization levels for functions that have many state changes, e.g. (R/W) of variable values within the function is what I read. 

5.11 This support assumes that most calls do not require a state change and are therefore optimized (in terms of code size and execution speed) for calls not requiring a state change. Using the DUAL_STATE pragma does not change the functionality of the dual-state support, but it does assert that calls to the applied function often require a state change. Therefore, such support is optimized for state changes.

That is not supported: We are talking about simple data manipulation by the main application and FAPI control of flash sectors. The Flash sectors are only for parameter storage that get copied to #pragma RAM and left behind in flash, not removed. These parameters can be read by FAPI calls to cycle through struct.compound variables. This is done on even older ARM MCU's with little to no difficulty with few changes for FAPI.

Is there a compiler switch to stop #pragma from moving the data from Flash instead copy it? I really don't reason why a flash loaded project would assume to move it's primary write from flash even by #pragma clause unless instructed to do so by the programmer.   

George Mock said:

No other method for managing the data is supported.  For instance, you cannot sometimes read from Flash, and then other times read from RAM.

Process doesn't need to be synchronous or duplex but does need to copy modified flash parameters to LSRAM via FAPI function calls. Not while the application is executing the main ISR task, rather when conditional branch disables the ISR to go update RAM variables as managed by the HID controlled FAPI routines.

That is not supported: There are no indirect memory address instructions in C2000, that would seem to allow data bus R/W via symbol address? I used to do that with Zilog z80 back in the day well before flash memory existed. Reading SRAM data by indirect addressing with single instruction loaded HL register pair for R/W address pointer and data piped into the accumulator.

So it might require adding C2000 assembler directives in the routine or simply define another section so both Ram and Flash have copy of the same data? 

BTW: #pragma .TI.Ramfunc() is in both flash and Ram due the Sections below.

  .TI.ramfunc : LOAD = FLASHB0_SA,
                         RUN = RAMLS2_3, //GS1_3,
                         LOAD_START(RamfuncsLoadStart),
                         LOAD_SIZE(RamfuncsLoadSize),
                         LOAD_END(RamfuncsLoadEnd),
                         RUN_START(RamfuncsRunStart),
                         RUN_SIZE(RamfuncsRunSize),
                         RUN_END(RamfuncsRunEnd),
                         ALIGN(4) 

// The RamfuncsLoadStart, RamfuncsLoadSize, and RamfuncsRunStart symbols
// are created by the linker. Refer to the device.h CMD file.
//
memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

George Mock said:

The current version of the C28x compiler manual does not mention dual state

Oddly the c2000 compiler folders (/man) are all empty and the project properties compiler TI.21.6.0.LTS omits the word C2000 that proceeds the compiler file name .  I simply thought TI had made a universal compiler for both CPU's based on the variant named. Thanks for the C2000 link, may add #pragmas to another ARM project for application enhancement. 

The issues with compound literal variable (1st example) has a broken pipe or missing CPU instructions. The CCS editor online code analysis lights up the compound variable placed in (RAM) but fails to transfer the #define value to the variable without a pointer no compound (.).

Then again it is no longer a compound variable by adding a pointer from the strut alias name to the variable that reads by (=) the define values. Oddly the #include does not hint the same typedef struct alias names and must be inside the function above the compound as in my first example, even after rebuilding the index the #include to the struct header is useless hint.

Since the compound variable pipe to the define resolves and compiles as a broken link, no data is read into the variable or CCS debug expressions with the same compound literals. There should be no need for a struct pointer and compound literal should resolve defined data. Since code analysis agrees the data pipe is not illegal syntax and functional. Some of expressions pointer issues missing debug data in literals were due to using *.h file for the struct and a long list macro loaded via #pragma. Listing of structure works better as C file typedef struct listing rather than list with macro header in the same *.h file (poor debug behaviors). The motor SDK have labs.h configured macro listing versus typedef struct C file list for the #pragma load.

6.15.1 Extensions: Compound literals give structures, unions, or arrays as values.

Genatco said:

The issues with compound literal variable (1st example) has a broken pipe or missing CPU instructions.

I don't understand your explanation of this problem.  For the source file with this code in it, please follow the directions in the article How to Submit a Compiler Test Case.  After you have created the preprocessed file, please add a comment to it similar to /* PROBLEM HERE */.

Thanks and regards,

-George

Oddly the compiler PDF does not show the name of joining any struct member to similar variable name via decimal point. It's not a union, pointer or compound and was used by TI in many ARM application via an undeclared two name structure without key word (typedef struct).

George Mock said:

I don't understand your explanation of this problem.

How difficult is it to see the above two example one works the other does not. The ARM instruction set or compiler does not have same problem to join struct members to referenced variable names via a delimiter between the two and defines passing value to the delimited member referenced variable. 

Taht is a data pipe by any other name but without a named pipe being used to transfer data.

Oddly the compiler PDF does not show the name of joining any struct member to similar variable name via decimal point. It's not a union, pointer or compound and was used by TI in many ARM application via an undeclared two name structure without key word (typedef struct).

George Mock said:

I don't understand your explanation of this problem.

How difficult is it to see the above two example one works the other does not. The ARM instruction set or compiler does not have same problem to join struct members to referenced variable names via a delimiter between the two and defines passing value to the delimited member referenced variable. 

That is a data pipe by any other name but without a named pipe being used to transfer data.

I'm sorry, but I don't follow what you are saying.  Please submit the test case I requested.

Thanks and regards,

-George

The compound only pass code analysis if the struct name and elements global export name are present in the function. The added #include holding the strut elements and global export name does not update the rebuilt index.  This seems to be a CCS issue being it occurs well before building the project.

I've noticed issue CCS 9.3 code analysis lack of ability to resolve some TI linked structures via #included file added to a C module. Even when the path is entered into the project properties where the exported global linked include can be found, compound variables do not resolve via CCS code analysis. Oddly CCS is not offering to update the index after the export global structure linked file path was added to project properties.

I'm not sure I understand.  Are you saying that the only issues of concern are related to the code analysis feature of CCS?  If that is correct, then please create a smaller, cut-down, CCS project which has the same problem.  Arrange things so that the problem is showing, take a screen shot, and attach it to your next post.  In addition, please zip up that CCS project as described in the article Sharing projects, and also attach that zip file.

Thanks and regards,

-George

One trick was to back off the include path to the named struct (*.h) file by one folder. The SDK had added as a pragma loaded #define name and linked typedef struct H file list. The SDK projects adding main tree folders that do not exist in the viewable paths under c:\ti make it difficult for importing or adding new code pieces.

Another observation, including a pragma loaded #defined named list directly above typedef structure in an H file does not work consistently after importing additional folders and rebuilding the index. The SDK projects should include C file with the pragma list as a named typedef struct inside the source folder with include folder H file for linking named struct elements. Then they are linked members of the C file strut, not just a single defined name for an H file list.

That seems to be most of the linkage issues with compound variables having defined values of another H file producing broken links via code analysis. There is no way to link a defined value to compound variable from a defined listing rather than a C file with matching typedef struct named elements to link with defined values. Below is the C file replacing the defined named listing via typedef structure and removing the defined named list from the H file.

#pragma DATA_SECTION(motorVars, "ctrl_data"); 
//!< and hardware board configuration
MOTOR_Vars_t motorVars; //MOTOR_VARS_INIT
//
//*****************************************************************************************
//

//! \brief Initialization values of global variables
//#define MOTOR_VARS_INIT
MOTOR_Vars_t motorVars = {

    false, /* flagEnableSys */
    false, /* flagEnableRunAndIdentify */
    false, /* flagRunIdentAndOnLine */
    false, /* flagMotorIdentified */
    false, /* flagSetupController */
    true,  /* flagEnableForceAngle */
    false, /* flagEnableRsRecalc */
    false, /* flagEnableRsOnLine */
    true,  /* flagEnableUserParams */
    true,  /* flagEnableOffsetcalc */
    false, /* flagEnablePowerWarp */
    false, /* flagBypassLockRotor */
    true,  /* flagEnableSpeedCtrl */
    true,  /* flagEnableCurrentCtrl */
    OPERATE_MODE_SPEED,  /* operateMode */
    false, /* flagStateMotorRunning */
	false, /* flagEnableFlyingStart */
    false, /* flagStateFlyingStart */
    FLYINGSTART_MODE_HALT,  /* flyingStartMode */
    0,     /* flyingStartTimeCnt */
    150,   /* flyingStartTimeDelay */
    0.0,   /* speedEst_Hz */
    false, /* flagEnableFWC */
    false, /* bool flagEnableMTPA; */
    false, /* bool flagUpdateMTPAParams; */

    CTRL_STATE_IDLE, /* ctrlState */
    EST_STATE_IDLE,  /* estState */
    EST_TRAJ_STATE_IDLE,    /* trajState */
    BOARD_BSXL8320RS_REVA,  /* boardKit */

    10.0,  /* speedRef_Hz */
    0.300, /* speedRef_krpm */
    0.0,   /* speedTraj_Hz */
    0.0,   /* speed_Hz */
    0.0,   /* speed_krpm */
    10.0,  /* accelerationMax_Hzps */
    100.0, /* accelerationStart_Hzps */

    USER_MAX_VS_MAG_PU,               /* overModulation */
    (0.1 * USER_MOTOR_MAX_CURRENT_A), /* RsOnLineCurrent_A */
    0.0,  /* magneticCurrent_A */
    0.0,  /* Rr_Ohm */
    0.0,  /* Rs_Ohm */
    0.0,  /* RsOnLine_Ohm */
    0.0,  /* Lsd_H */
    0.0,  /* Lsq_H */
    0.0,  /* RoverL_rps */
    0.0,  /* flux_VpHz */
    0.0,  /* flux_Wb */
    0.0,  /* torque_Nm */

    0.1,  /* Kp_spd */
    0.01, /* Ki_spd */

    0.5,  /* Kp_Id */
    0.01, /* Ki_Id */

    0.5,  /* Kp_Iq */
    0.01, /* Ki_Iq */

    USER_FWC_KP, /* Kp_fwc */
    USER_FWC_KI, /* Ki_fwc */
    USER_FWC_MAX_ANGLE_RAD, /* angleMax_fwc_rad */

    (0.8 * USER_MAX_VS_MAG_PU), /* VsRef_pu */
    (0.8 * USER_MAX_VS_MAG_PU  * USER_NOMINAL_DC_BUS_VOLTAGE_V), /* VsRef_V */
    0.0,  /* Vs_V */
    0.0,  /* VdcBus_V */

    0.0,  /* IdRated_A */
    0.0,  /* IdTarget_A */
    0.0,  /* Is_A */
    0.0,  /* IsRef_A */
    0.0,  /* anglePhase_rad */

    {IA_OFFSET_A, IB_OFFSET_A, IC_OFFSET_A}, /* offsets_I_A */
    {VA_OFFSET_V, VB_OFFSET_V, VC_OFFSET_V}, /* offsets_V_V */

    0.0,  /* power_sf */
    0.0,  /* power_W */

    0.0,  /* IsFilter_A */
    0.0,  /* VsFilter_V */
    0.0,  /* VbusFilter_V */

    0.0,  /* IqRefAbs_A */
	0.0,  /* IqFdbAbs_A */

    0.0,  /* speedFdbAbs_Hz */
    0.0,  /* speedRefAbs_Hz */
    0.0,  /* speedRefDelta_Hz */
    0.0,  /* speedFdbDelta_Hz */
    0.0,  /* speedRefDeltaSet_Hz */

    0.0,  /* float32_t mtpaConstant */
    0.0,  /* float32_t LsOnline_d_H */
    0.0,  /* float32_t LsOnline_q_H */
    0.0,  /* float32_t fluxOnline_VpHz */

    0,  /* estISRCount */
    0,  /* pwmISRCount */
    0,  /* mainLoopCount */
    0,  /* timerCnt_1ms */

2048 + 512, /* dacValH(+Peak)*/
2048 - 512, /* dacValL(-Peak)*/
	2048, /* dacaVal */
    2048, /* dacbVal */
    0,  /* faultNow */
    0,  /* faultUse */
    0   /* faultMask */

};

Unfortunately, I don't understand your post very well.  It appears you have found a way to resolve part of your problem with code analysis.  If any other problems remain, please submit a test case for them as I requested in my last post.

Thanks and regards,

-George

Simply don't add defined lists that reference typedef struct elements in the same H file. Make the list as shown above a struct in a C file.