When working with a C6000 DSP, where are xdc_Uint* types defined?

Aha!  I was looking in the wrong place.  On my install there's a \ti\ folder above the product folders.

I have found ti\xdctools_3_24_05_48\packages\ti\targets\std.h which  contains the typedefs for the xdc_UInt* types.

On line 106:

/*
 *  ======== [U]Int<n> ========
 */
typedef int_least8_t    xdc_Int8;
typedef uint_least8_t   xdc_UInt8;
typedef int_least16_t   xdc_Int16;
typedef uint_least16_t  xdc_UInt16;
typedef int_least32_t   xdc_Int32;
typedef uint_least32_t  xdc_UInt32;

#ifdef xdc__INT64__
    typedef int_least64_t   xdc_Int64;
    typedef uint_least64_t   xdc_UInt64;
#endif

Tracing further, I see that uint_least*_t is defined in my compiler: ti\ccsv5\tools\compiler\c6000_7.4.1\include\stdint.h and that it traces back to primitive types. 

So now that I understand this branch of the typedef tree, my next question is: Why can't CCS5.3 find ti\xdctools_3_24_05_48\packages\ti\targets\std.h which contains the typedef for xdc_UInt*?  Is my project setup incorrectly?

Can you post the exact error message that you are seeing? There are two different set of types, one with an uppercase I (xdc_UInt16 for example) and then a set with a lowercase I (Uint, for example). I can't really tell which of these is not being found.

My apologies,

I mistyped capitalization in all of my posts thus far.  I just went back through and edited them for clarity.  Unfortunately, I don't have an error message I can show you.  The reason I know I have an error is because I am unable to trace my type tree back to primitive types using Navigate -> Open Declaration (F3) command in CCS5.3.  To address your previous post directly, I believe that xdc_UInt* (uppercase I) is not being found.

Based on your previous responses, I've figured out what my type tree should look like:

• primitive types

• • uint*_t (lowercase i)

• • • uint_least*_t (lowercase I)

• • • • xdc_UInt* (uppercase I)

• • • • • Uint* (lowercase I)

In other words:

1. The types that my code base uses are Uint* (with lowercase i)
2. The parent types of Uint* are xdc_UInt* (with uppercase I) defined in ti\xdctools_3_24_05_48\packages\xdc\std.h
3. The parent types of xdc_UInt* are uint_least*_t (with lowercase i) defined in ti\xdctools_3_24_05_48\packages\ti\targets\std.h
   1. This is the link that seems to be broken
4. The parent types of uint_least*_t are uint*_t (with lowercase i) defined in ti\ccsv5\tools\compiler\c6000_7.4.1\include\stdint.h
5. The parent types of uint*_t are primitive types defined in ti\ccsv5\tools\compiler\c6000_7.4.1\include\stdint.h

At this point, there are several ways I could force the typedefs to work, either by editing some of these standard header files, or by creating my own file that defines Uint* directly to primitive types.   But I think both options would decrease my code base's portability.  I want to know how to make this tree work automatically.

EDIT: I just realized my project has an alternate place that it might get it's Uint* type definitions from:  \ti\pdk_C6678_1_0_0_21\packages\ti\csl\tistdtypes.h. 

Perhaps that's my problem?  I have two different files attempting to define Uint*

/* Handle the 6x ISA */
#if defined(_TMS320C6X)
    /* Unsigned integer definitions (32bit, 16bit, 8bit) follow... */
    typedef unsigned int	Uint32;
    typedef unsigned short	Uint16;
    typedef unsigned char	Uint8;

    /* Signed integer definitions (32bit, 16bit, 8bit) follow... */
    typedef int			Int32;
    typedef short		Int16;
    typedef char		Int8;

It is very likely that defining the same type twice could cause a problem. Which of these do you want to use? If you want to use ones from PDK, and hide the definitions coming from XDCtools, you can use xdc__strict macro (rtsc.eclipse.org/.../Integrating_RTSC_Modules) to achieve that. Here is a thread with a similar use case: e2e.ti.com/.../1431152

If you want to use the ones from XDCtools, you would either have to not include the header files from PDK, or you would have to edit that file. I am not aware of any mechanism similar to xdc__strict.

I'm all for moving away from deprecated functionality.  So, per the link you sent, I added the following line to my compile flags:

cl6x -Dxdc__strict -Dxdc_target_types__=ti/targets/std.h -Dxdc_target_name__=C66

However, I end up with the following error:

Fatal error #5: could not open source file "cl6x"

Perhaps I should remove the cl6x?

I'm thinking I may have bigger issues so I'm going to take a quick step back.

You mentioned:  

The rest of the string you added to compile flags should already be a part of the command line, and there is no need to add it.

I actually don't have them defined.  And through a bit of searching I've realized that I'm suffering from the same issue listed in this thread:  https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/257493

I've only defined my device variant as a "Generic C66xx Device"

I'm working with my IT department to get the keystone1 version 1.0.6.0 update.

Am I correct in thinking that defining my device variant as TMS320C6678 might resolve my typedef woes by defining my xdc_target_name and xdc_target_types (and any other fancy magic it does) automatically for me?  Perhaps this is the better option rather than mucking about with the compiler options myself.

Also, how do I remove "cl6x" from my compile options now?

My apologies, but I cannot share my full build console output.  I'm afraid that my filenames and paths may reveal proprietary and personal information that would get me in trouble with my employer. 

I was able to resolve a couple of my questions however they didn't seem to fix my original typedef dilemma:

1. In a previous post, I added several compile flags by clicking the Set Additional Flags... button under Project -> Properties -> CCS Build -> CCS Compiler.  By doing so, I accidentally added "cl6x" to the end of my compiler invocation.  Based on my build console output, I think it was trying to use "cl6x" as a compiler.  I deleted the following option from my .cproject file and my "cl6x" errors went away.

   <listOptionValue builtIn="false" value="ADDITIONAL_FLAGS__COMPILER=cl6x"/>
   

    

2. Additionally, I was able to work with my IT department to apply the keystone1 v1.0.9.1 update that I was previously missing.  I am now able to find TMS320C6678 in the device variant dropdown on Project -> Properties -> CCS General -> Main -> Variant.  However, changing this setting did not automatically fix all my typedef errors like I hoped it would.

So I went back to trying the xdc defines you pointed me to.

1. I added all three predefined symbols:  xdc__strict, xdc_target_types__=ti/targets/std.h, and xdc_target_name__=C66 and attempted to build.  This caused my PDK to throw thousands of errors, complaining that all the Uint* and Int* types were undefined.
2. So I removed xdc__strict.  At this point my compile flags looked like the following (minus any revealing --include_path flags):

   -mv6678 --abi=eabi -g --include_path="C:/Apps/ti/ccsv5/tools/compiler/c6000_7.4.1/include"  --include_path="C:/Apps/ti/pdk_C6678_1_0_0_21/packages/ti/csl" --include_path="C:/Apps/ti/pdk_C6678_1_0_0_21/packages/ti/platform" --include_path="C:/Apps/ti/pdk_C6678_1_0_0_21/packages/ti/drv/qmss" --include_path="C:/Apps/ti/pdk_C6678_1_0_0_21/packages/ti/drv/cppi" --gcc --define=_TI_ENHANCED_MATH_H --define=_DEBUG --define=xdc_target_types__=ti/targets/std.h --define=xdc_target_name__=C66 --display_error_number --diag_suppress=232 --diag_suppress=179 --diag_suppress=195 --diag_suppress=238 --diag_suppress=552 --diag_suppress=880 --diag_suppress=190 --diag_suppress=682 --diag_suppress=1116 --diag_suppress=183 --diag_suppress=681 --diag_suppress=188 --diag_suppress=270 --issue_remarks --diag_warning=225 --gen_func_subsections=on --mem_model:data=far --std_lib_func_defined --output_all_syms

   
   This time I only receive a couple of errors, most notably:  #20 identifier "Uint8" is undefined and #20 identifier "Uint32" is undefined.