LAUNCHXL-F280049C: CCS9.3 & CCS12.4 symbol not defined though it resolves in editor

Hello,

Genatco said:

but the linker can't find the symbol by the referenced include in the calling C file?

Can you show me the error you're seeing?

Genatco said:

Hint: After adding library path to the symbols files properties tab of the defined extern symbol a new error message appears "Cannot open the file permission denied"

New error seems to be caused by Windows 10 file security indicating CCS did not add a name to Users group during CCS setup or importing the project via REX to the new folders being created.

#6001 cannot open file "C:/ti/c2000/C2000Ware_MotorControl_SDK_4_00_00_00/libraries/observers/est_lib":  Permission denied

Make sure you have proper permissions for the file directory CCS and C2000Ware are downloaded in, and there is no firewall restrictions for CCS (or that CCS is excluded from any such security restrictions).

Best regards,

Omer Amir

Hi Omer,

I edited that second question out, oddly you were still seeing it.

The symbol (estHandle) is not resolving during linking. It seems the original project did not have a global export for the (estHandle) and functions could not be used by added C file callers (commands.c). Functions are needed for motor control in universal MCSDK FAST estimator inline. Oddly the extern symbol pointer works without issues SDK yet not resolve MCSDK during linking. The caller casting extern symbol (estHandle) to (est.h) inline functions are the same call both projects.

Below exported struct handle pointer for each inline function (est.h) cast by caller. There is ongoing issue Boolean flag variables defined in typedef structs (bool) do not link state changes from custom modules added to MCSDK example project. Yet the very same bool logic flags (userParams.h) do change state when toggled true/false from (commands.c) SDK example project. We have to develop custom applications around existing example modules as they are specialized TI proprietary library calls for FAST estimator control (est.h).

commands.c: EST_setFlag_enableRsRecalc(estHandle, false);

est.h: //! \brief Defines the estimator (EST) handle
          typedef struct _EST_Obj_ *EST_Handle;

          extern EST_Handle estHandle;

Type Description Resource Path Location
C/C++ Problem unresolved symbol estHandle, first referenced in ./src_control/fexton/commands.obj is15_uvmcsdk_f28004x
C/C++ Problem <a href="file:/C:/ti/ccs1220/ccs/tools/compiler/dmed/HTML/10234.html">#10234-D</a> unresolved symbols remain is15_uvmcsdk_f28004x
C/C++ Problem #10010 errors encountered during linking; "is15_uvmcsdk_f28004x.out" not built is15_uvmcsdk_f28004x
C/C++ Problem gmake[1]: *** [is15_uvmcsdk_f28004x.out] Error 1 is15_uvmcsdk_f28004x
C/C++ Problem gmake: *** [all] Error 2 is15_uvmcsdk_f28004x

Hello,

I see you have the extern declaring the estHandle, but do you also have where it is defined? Extern will only say that the variable/pointer exists, but it has yet to be resolved/defined in another file (I'm replicating this on my side, so if you can provide this I will try to debug further).

Best regards,

Omer Amir

Yes the Handle is defined as a typedef struct above post.

I found a work around WA is to remove extern alias pointer(estHandle) in the function/s (est.h). Requires to also remove (obj->estHandle) pointers in caller/s MCSDK project that share inline functions est.h. Then the linker has no problem since the symbol is not used. Though what captures my eye is the extern symbol and function both have keyword (extern). This WA will not affect SDK project since it uses a different folder path, est_lib.

Example: (est.h): extern void EST_setFlag_enableRsRecalc(const bool state); // remove {EST_Handle handle,}

Callers sharing same function (motor1_drive.c): EST_setFlag_enableRsRecalc( obj->flagEnableRsRecalc); //remove{obj->estHandle,}

/cfs-file/__key/communityserver-discussions-components-files/171/est.zip

Hello,

I'm sorry, I don't understand your post. I was able to recreate what I think the situation you have is, and built the main code without a problem.

main.c:

#include "temp.h"

int funcCaller(newStruct thing, bool val);

//
// Main
//
void main(void)
{
    newStruct estHandle;
    int newNum;
    while(1)
    {
        newNum = funcCaller(estHandle, false);
    }
}

int funcCaller(newStruct thing, bool val)
{
    int a = 0;
    thing->t = 0;
    thing->y = 1;
    if(val)
    {
        a = 1;
    }
    else
    {
        a = 2;
    }
    return a;
}

temp.h:

struct _newStruct_{
    int t;
    int y;
};
typedef struct _newStruct_ *newStruct;
extern newStruct estHandle;

You did not show me how you defined the struct or estHandle, so I did it on my end and the project built without a problem.

Best regards,

Omer Amir

The typedef struct is the handle for casting into the functions of est.h via use of a pointer (estHandle). The zip file est.h is posted above. The linker does not like keyword extern on these functions and estHandle pointer seemingly constituted a double decelerative condition. When there is not extern estHandle pointer back to the typedef struct (*EST_Handle) it will not resolve in the custom module added into project even after adding #include path to where the extern symbol is defined top of est.h. It seems the editor no longer resolves symbols into the index from #includes top of C files as it once did in earlier versions of CCS. The index seems to scan open C modules editor prebuild syntax and ignores the #includes during linking. 

est.h: //! \brief Defines the estimator (EST) handle
          typedef struct _EST_Obj_ *EST_Handle;

extern Handle  estHandle; 

The header file you've attached is one I'm unfamiliar with and is over 7000 lines of code. You'll need to tell me where the estHandle and _EST_Obj_ are defined, not declared, otherwise I will be unable to offer any help. What you've shown me is how it's declared, i.e. telling the compiler the variable exists. What I need to understand is how it is defined as, i.e. what values/parameters/properties it has. If a symbol is indicated to be unresolved by the compiler, it means you've declared it (i.e. with an extern), and not defined it (in your case, it would need be globally defined because of the extern). I've shown you in my code how both _newStruct_ and estHandle are defined, and this results in no unresolved symbol errors.

Omer Amir said:

You'll need to tell me where the estHandle and _EST_Obj_ are defined, not declared

Below struct defines (estHandle) that fails to link or cast to the inline functions of est.h. The EST_Handle define below typedef struct that is not causing any issues other than bool flag states are not linked to the added module out of debug mode. Oddly my above WA compiled without any errors though 3 functions did not work without the handle being cast into the functions. The two bool flags fail to link runtime Boolean state changes into conditional statements of customer added modules, yet they compile without any errors in customers module.

Does not matter what memory section (M0-1, LS0-7, GS0, GS1 etc.) the typedef defines are loaded estHandle symbols do not work. And bool flags do not execute link state changes into other modules they exist in coded examples outside of debug. The bool flags and estHandles are only valid in CCS debug. Seems out to bin file conversion of UniFlash removes some symbols. Only seems to remove symbols from MCSDK project as SDK project all bool flags assert and pass state changes via customers added modules out of debug mode. 

Also attempted to create *bin executable file enabling C2000 hex utility. The image *.bin file did not work loaded 0x00080000 (code_start) being very complicated setup and has check box for *bin file. Executable *bin file loaded with a warning message, "Sections attempted to write to protected memory sections was ignored." It seems there are two issues, not just symbols not found error during linking.

There exists a guide how to setup C2000 hex utility to make non-OS binary file?

The odder part being there was no extern estHandle in the project pointing back to EST_Handle defined below. I created extern above trying to fix missing symbol error during linking. The compiler would not allow the extern placed being below this struct.  

defined motor_common.h :

//******************************************************************************
// typedefs
typedef struct _MOTOR_Vars_t_
{
  // the handle for the estimator
  EST_Handle estHandle;

  bool flagEnableRunAndIdentify;
  bool flagRunIdentAndOnLine;

} MOTOR_Vars_t;

//! \brief Defines the MOTOR_Vars_t handle
//!
typedef struct _MOTOR_Vars_t_ *MOTOR_Handle;

Hello,

You are including a lot of extraneous information in your replies that makes it difficult to read through and understand your problem. I will only be addressing the main problems that are occurring to help speed up this solution.

The code you include above for _MOTOR_Vars_t_ shows that is uses EST_Handle in the struct, but where is _MOTOR_Vars_t_ defined? This is just a declaration, even if estHandle is in the struct it is not yet in use or defined.

Best regards,

Omer Amir

That is the defined symbol in the typedef struct, there is no #define is this project for EST_Handle and _MOTOR_Vars_t_  is considered the tag name of the struct as I understand.

Hello,

Let me correct what I said, where is MOTOR_Handle defined? The typedef declares that MOTOR_Handle is a type, but I don't see any MOTOR_Handle variable defined of this type. (#define is not defining a variable, this creates a macro).

Best regards,

Omer Amir

Hello Omer Amir,

Omer Amir said:

The typedef declares that MOTOR_Handle is a type, but I don't see any MOTOR_Handle variable defined of this type.

The (*) before the handle name (*MOTOR_Handle) points into _MOTOR_Vars_t_ struct where the member symbols exist. It's not a variable rather looks like a struct pointer to another struct above it. I despise all this handling anyway for the very reasons the linker is not resolving the symbol name (estHandle). Though the CCS editor byline code analysis and indexer does resolve (estHandle) makes one believe the linker should too.

I didn't write this code, came from TI engineering. You can load this project into CCS via REX SDK4.0 and universal MCCSDK 4.0 shares some files from folders of SDK. The later universal MCSDK project v4.02.01 adds even more new symbols. 

Hello,

I have the latest C2000Ware_MotorControl_SDK_4_02_01_00 and tried building the universal motor control solutions (both SysConfig and non-SysConfig versions). The project built with no errors or warnings at all. I recommend importing one of these projects and copying your program code into the example to use. I'm not sure how to help you further, since I cannot replicate the errors you are getting. I recommend using the SysConfig version of the universal MCSDK project so you can migrate to the F28004x device easily (I did not see this device listed in the SDK solutions for the universal lab).

Best regards,

Omer Amir

Hello,

I tried using the universal_motorcontrol_lab_f28003x example, and inserted the following code at the very top of main:

#include "est.h"

void main(void)
{
    EST_Handle var;
    float32_t temp = EST_computeTorque_Nm(var);
    ...
}

There were no errors, and the only warning was that I was using var before it was initialized.

Genatco said:

try to call any function in (est.h) links to fast_full_lib_eabi.lib functions

If there is a specific function you want me to use on my side, let me know (I have not used the Universal Motor Control lab before, so I'm unfamiliar with the many functions in the est.h file).

Genatco said:

Add a folder to the UMCSDK project path

If you're using the universal motor control project, why do you need to add a folder path? From what I can tell looking at the project properties, there are already several file paths (including for est.h):

I do understand that this is a frustrating problem, but I have not heard of any other customer having this kind of issue with the universal motor control lab. Have you added any other custom modifications to the project, such as modifying the project properties beyond what you've told me? Is the project you have based on an older version of the universal lab which you are trying to use with the current version of the MCSDK, or is this a fresh new project for the 4.02.01.00 MCSDK?

Best regards,

Omer Amir

Omer Amir said:

I tried using the universal_motorcontrol_lab_f28003x example, and inserted the following code at the very top of main:

My custom modules exist in a folder added to the project path tab of SDK and universal MCSDK v4.0 project builds shown below.

So calls to est.h come from the include path tab where my C modules exist and has #include "est.h" at the top where the functions are being called. There are 4 C modules in my folder used to control the SDK and MCSDK bool flags, monitor variables when or if launched without CCS debug. SDK4.0 motor control compiles and controls the very same functions of est.h via my C files folder path.

However the C files that symbols correctly execute exist closer to the top of the SDK project tree (on disk) shown below folder paths. My added folder C files had to be rewritten since the symbol names to the struct were changed in UMCSD. Hence that requires to have the same folder exist in two places down the disk tree. Suspect that could be why the linker is not resolving the lower symbols during linking only when my C code calls any functions est.h UMCSDK.

Otherwise both projects compile without any linking errors when No calls are made to est.h, that also exists in two places down the drive tree (\est & \est_lib). Seemingly the linker search path down hard disk tree and somehow finds first folder (exton\commands.c) where the same file name also exists closer to the top of C drive tree. Yet IDE correctly compiled the second MCSDK folder file (\exton\command.c). Seemingly this is a linker path issue, not a compiler path issue though I assumed since the compiler used the project includes tab to find the symbols the linker might do the same.

SDK: C:\ti\c2000\C2000Ware_MotorControl_SDK_4_00_00_00\libraries\exton\commands.c

UMCSDK: C:\ti\c2000\C2000Ware_MotorControl_SDK_4_00_00_00\solutions\universal_motorcontrol_lab\f28004x\drivers\exton\commands.c

BTW: This issue was not resolved and thank you Omer for persistent assistance 

Hi,

Genatco said:

Test: Add a folder to the UMCSDK project path, create a link to custom C file and try to call any function in (est.h) links to fast_full_lib_eabi.lib functions.

What do you mean by "create a link to custom C file"? est.h file gets linked in to the folder below and pulled from ${SDK_ROOT}/libraries/observers/est_lib/include

Can you provide screenshots of your error from your CCS workspace? I'm not clear what you're experiencing now.

Best,

Kevin

Hi Kevin,

Kevin Allen18 said:

What do you mean by "create a link to custom C file"? est.h file gets linked in to the folder below and pulled from ${SDK_ROOT}/libraries/observers/est_lib/include

Under MCSDK project import a virtual link to an added custom C file folder path as to control state changes of existing project flag names or call the embedded project TI functions. Even by adding *obj pointer to the customers function header the linker still fails to resolve estHandle during compile only. Also renamed above folders where path had same name (exton) and even moved it under libraries folder of SDK project made no difference linker to resolve symbol estHandle. So the Boolean flags compile and link but do not work without XDS110 simulator in standalone mode. Below only error to indicate MCSDK project is not linking correctly all of the modules. So many project handles appear to challenge linker even with recursive library symbol checks, omitts vital linking instructions XDS110 debug mode covers up. The SDK project does not have any of these issues and is the control for the MCSDK experiment.

Kevin Allen18 said:

Can you provide screenshots of your error from your CCS workspace?

Type Description Resource Path Location
C/C++ Problem unresolved symbol estHandle, first referenced in ./src_control/fexton/commands.obj is15_uvmcsdk_f28004x
C/C++ Problem <a href="file:/C:/ti/ccs1220/ccs/tools/compiler/dmed/HTML/10234.html">#10234-D</a> unresolved symbols remain is15_uvmcsdk_f28004x
C/C++ Problem #10010 errors encountered during linking; "is15_uvmcsdk_f28004x.out" not built is15_uvmcsdk_f28004x
C/C++ Problem gmake[1]: *** [is15_uvmcsdk_f28004x.out] Error 1 is15_uvmcsdk_f28004x
C/C++ Problem gmake: *** [all] Error 2 is15_uvmcsdk_f28004x

As you can see below the pointer symbol resolved in the index and editor code analysis via check syntax as you type selected project properties. Also added a path to the est.h file in the linker library paths tab, linker still cannot find symbol estHandle. Worst of all none of the Boolean flags (_MOTOR_Vars_t_) struct execute or indicate state changes in the any customer provide functions when the flag state changes in any MCSDK module. These issues are seemingly linker failures as there are no functioning Boolean control links between customer modules and TI proprietary modules.

The MCSDK bool flags only work in debug mode not from customer added functions even run in debug or standalone. Seemingly XDS110 Simulator *.out file code conversion covers up missing linker issues in debug mode. And Uniflash strips off symbols that make the project mostly dysfunctional when XDS110 is not connected. Yet the same customer added modules to SDK4.0 work in either CCS debug or standalone mode without XDS110 control states and after Uniflash firmware loads into launch pad.

 BTW: Communications, Sfra excluded from the project build

Symbols: MOTOR1_DSCLINKSS_N, TEST_ENABLE_N, MOTOR1_FAST, MOTOR1_ESMO.