RTOS/EK-TM4C1294XL: RTOS package available products tree is missing drivers/boards/examples folders sub items.

Hi BP101,

What products do you have included and which version of XDCtools are you using (Project Properties->General->Products). For example this example is using XDCtools 3.32.00.06 and TI-RTOS 2.16.01.14.

Seems we have a conflict of interest? Main already exist in the earlier version of RTOS 2.06.0.08 project build, blue dot.  

The projects tool set is an RTOS board feature EK-TM4C1294XL but exist under same name Main and refuses to write the configuration file.

Hi Todd,

XDCTools  V3.32.2.25 core.

The same one you have above makes no difference to populate the tool chain related parts. I found where main was place in RTOS config  file but save did not populate (Main, red dot) to the Outline even after compiled. Refresh available products makes no difference either after compile.

var TIRTOSProductView = xdc.useModule('ti.tirtos.productview.TIRTOSProductView');
var examples_examplesgen_Main = xdc.useModule('examples.examplesgen.Main');

I tried to clean then compile with and without UIA checked. Refresh the product list, even close reopen CCS, still no boards examples or drivers.

Background

The Available Products view shows the modules that can be configured in the .cfg file.

If there is a red dot, it means it is a build world only module (e.g. there is no target code associated to that module.  A red module might bring in some target code, but does not author it. An example of a red module is ti.driver.Config. You can say to include the instrumented or nonInstrumented library, but there is no Config_xyz() runtime API.

A blue dot denotes a module that has target code. For example the ti.sysbios.knl.Task module has a blue dot because there is Task configuration and associated target code (e.g. Task.numPriorities is a configuration parameter and Task_sleep is a runtime API).

Where are the driver modules?

To get into the Available Products, the module has to be an XDC module. All of the kernel and UIA modules are XDC modules. The driver module (e.g. UART, I2C, etc.) are not XDC modules, and therefore not show up in the view. Note: older versions of TI-RTOS did have driver modules as XDC modules, so UART did show up. We moved away from that several releases ago and are using the ti.drivers.Config module to select instrumented vs nonInstrumented.

Where are the board modules?

ditto from above. The are no XDC modules associated with the boards. You could argue that that should not be listed, and you are probably right.

What is xdc.runtime.Main?

Non-XDC modules (e.g. application code and TI-RTOS drivers) still might want to do logging or assert checking. The xdc.runtime.Main module allows configuration of these modules. For example, you can create a logger for xdc.runtime.Main and all calls to Log_writeX will go to that logger.

The reason why I asked for you settings is because I don't understand why tirtos_tivac_2_16_01_14 is showing up in your Available Products. Here is mine

Can you import an example from TI-RTOS 2.16.01.14 and open the .cfg with XGCONF. Do you still see the  tirtos_tivac_2_16_01_14 entry?

Hi Todd,

Sorry for delay to reply as TI emails were in junk folder for no good reason.

ToddMullanix said:

The reason why I asked for you settings is because I don't understand why tirtos_tivac_2_16_01_14 is showing up in your Available Products. Here is mine

Rather the Tidrivers 2.16.01.13 are considered Other available products, seemingly as a sub folder to RTOS library files shown top of available products view as TI-RTOS & XDCtools. 

I don't seem to understand your points as the boards, examples are not being generated in the tree as the (open hover box) in my post above suggest should occur. Why wouldn't boards/drivers be in the available products tree is my counter any idea they should not be listed there. I actually had UIA checked for RTOS analyzer load module but unchecked it to match for testing this issue. Made no difference no matter what version of XDC or RTOS are compiled with several RTOS projects existing in the CC7 project tree, nor recently imported projects the list folder remain empty of drivers content.

Perhaps RTOS drivers are not being listed in your Other Available products too indicates folder propagation failure? In my case boards/drivers files exist under C:\CCS7.3\ RTOS 2.13.01.14\ products folder, no longer at C:\ti as the original projects RTOS 2.16.0.08 still exists. BTW CCS7 Resource Explorer does not have latest RTOS version 2.16.01.14 files posted RTOS files tree, further complicates the matter. So it seems the produts tree should now show all TM4C boards/drivers/examples since CCS7.x REX cloud posting of RTOS versions has been deprecated?

Ok - now see your tree posted above is missing the TI-RTOS packages folder. Question then is why would not a products tree include a packages folder in your case.

Tried to import RTOS example Watchdog into CC7 project tree but wizard returns error not recognized as CC7 project, seemingly it must be TI-RTOS Watchdog driver file not showing in the tree. Perhaps the reference in XDC tools may be how the TI-RTOS path is being added to the Available Products tree.

ToddMullanix said:

The xdc.runtime.Main module allows configuration of these modules. For example, you can create a logger for xdc.runtime.Main and all calls to Log_writeX will go to that logger.

Oddly the XDC main module in RTOS 2.16.01.14 also shows it can create example project folders using MAK from a top level builds.  Wonder how to do make since import project wizard can not recognize the board level examples, yet are listed in the wizard view pain for every type of TM4C launch pad & IDE. So it seems the examples are there but not accessible as RTOS boards we can easily get too, import and access inside an empty RTOS project. At least then it becomes obvious to the New Bee the RTOS files on C drive device folder have a purpose.

Again more so needed since the specific board examples are not uploaded to REX cloud server and the wizard is choking.

BP101 said:

Oddly the XDC main module in RTOS 2.16.01.14 also shows it can create example project folders using MAK from a top level builds.

I don't understand what you mean. Please note, tirtos_tivac_2_16_01_14 should not be showing up in "Available Products". Something is messed up with your install.

BP101 said:

This issue is likely my bad for believing the watchdog and other TM4C peripherals are actually RTOS driver modules that also exist in EK_TM4c1294XL.c boards file and similarly should have a GUI configuration page viewable from TI-RTOS.cfg file..

The TI-RTOS drivers configuration is in the board file (i.e. EK_TM4C1294XL.c) and not in the .cfg.

ToddMullanix said:

Please note, tirtos_tivac_2_16_01_14 should not be showing up in "Available Products". Something is messed up with your install.

The RTOS root folder path holds all the other package for RTOS configuration and seemingly compiler linker paths else many Symbol errors occur during compile. If what you say was entirely true you would not be able to install the UARTMon support into RTOS for GUI composer.

ToddMullanix said:

The TI-RTOS drivers configuration is in the board file (i.e. EK_TM4C1294XL.c) and not in the .cfg.

To further clarify; Config(ti.mw) middleware settings control for instance WiFiCC3X00LIB in EK_TM4C1294XL.c board being added to the build or not, as it was in the past configurations.

The 4 Boolean switches exist in the RTOS configuration and enable/disable functions of EK_TM4C1294XL.c, such as disable WiFiCC3100=false. That now fails with symbol error in RTOS 2.16.01.14 that points to EK_TM4C1294XL.c. I'd like to see the same XDC directives for all devices that exist inside EK_TM4C129XL.c and some kind of GUI icon in the outline to quick access those controls as WiFiCC3100 middleware function does.

var ti_mw_Config = xdc.useModule('ti.mw.Config');
ti_mw_Config.provideWiFiCC3X00Lib = false;
ti_mw_Config.provideDisplayLib = false;
ti_mw_Config.provideGrLib = false;
ti_mw_Config.provideLCDLib = false;

Can you paste the first part of a rebuild log? I want to see how you are building this. For example

"C:\\ti\\ccs7_3_0_00010\\ccsv7\\utils\\bin\\gmake" -k -j 4 all -O

gmake[1]: Entering directory 'C:/workspace/tiva_standalone_config/empty_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT/Debug'

'Building file: ../empty.cfg'

'Invoking: XDCtools'

"C:/ti/xdctools_3_32_00_06_core/xs" --xdcpath="C:/ti/tirtos_tivac_2_16_01_14/packages;C:/ti/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages;C:/ti/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages;C:/ti/tirtos_tivac_2_16_01_14/products/ndk_2_25_00_09/packages;C:/ti/tirtos_tivac_2_16_01_14/products/uia_2_00_05_50/packages;C:/ti/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages;C:/ti/ccs7_3_0_00010/ccsv7/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.M4F -p ti.platforms.tiva:TM4C1294NCPDT -r release -c "C:/ti/ccs7_3_0_00010/ccsv7/tools/compiler/ti-cgt-arm_17.6.0.LTS" --compileOptions "-mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path=\"C:/workspace/tiva_standalone_config/empty_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT\" --include_path=\"C:/workspace/tiva_standalone_config/empty_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT\" --include_path=\"C:/ti/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b\" --include_path=\"C:/ti/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages/ti/sysbios/posix\" --include_path=\"C:/ti/ccs7_3_0_00010/ccsv7/tools/compiler/ti-cgt-arm_17.6.0.LTS/include\" --define=ccs=\"ccs\" --define=PART_TM4C1294NCPDT --define=ccs --define=TIVAWARE -g --gcc --diag_warning=225 --diag_warning=255 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi  " "../empty.cfg"

ToddMullanix said:

The TI-RTOS drivers configuration is in the board file (i.e. EK_TM4C1294XL.c) and not in the .cfg.

The Example drivers are seemingly just another type of RTOS middle ware, import MAK metadata is corrupted. The new package library files of TI-RTOS 2.16.01.14 build are totally different from past builds.

**** Build of configuration Debug for project rtos_empty ****
 <Linking>

undefined first referenced
symbol in file
--------- ----------------
SemPost C:/CCS7v3/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages/ti/drivers/lib/drivers_tivaware.aem4f<EMACSnow.oem4f>
WiFiCC3100_fxnTable ./EK_TM4C1294XL.obj

error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "rtos_empty.out" not built

gmake[1]: *** [rtos_empty.out] Error 1
>> Compilation failure
makefile:188: recipe for target 'rtos_empty.out' failed
gmake: *** [all] Error 2
makefile:180: recipe for target 'all' failed

**** Build Finished ****

There are various things wrong with this. How was this project created?

ToddMullanix said:

There are various things wrong with this

How can you even be totally objective when your XDCtools core version is so out of date, ergo (C:/ti/xdctools_3_32_00_06_core/xs)  All those XDCtools includes you show in your project build above are no longer part of the rtos_empty project import. Seemingly the RTOS examples, e.g. (rtos_empty) project has to be compatible with TI-RTOS XDCtools versioning added includes for middle ware platform directives that are part of the target platform. How can TI expect anyone to build an RTOS project from empty source that the XDCtools version Includes are void? KISS rules in that scenario, does it not? Seemingly XDCtools build properties does not need to Flag includes for source code it does not manage as part of the RTOS platform build of a target. IE: Below XDCtools build FLAGS should suffice to disable middle ware via Boolean switches as added to RTOS configuration, so the linker never sees Symbols being passed from the make build.

xdcpath="C:/CCS7v3/xdctools_3_32_02_25_core;C:/CCS7v3/tirtos_tivac_2_16_01_14/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/ndk_2_25_00_09/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/uia_2_00_05_50/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.M4F -p ti.platforms.tiva:TM4C1294KCPDT -r debug -c "C:/CCS7v3/ccsv7/tools/compiler/ti-cgt-arm_16.12.0.STS" -w

ToddMullanix said:

How was this project created?

Used CCS project Import wizard; RTOS 2.16.01.14 Examples\  rtos_empty project. There was not an RTOS configuration file in the empty project. Used wizard to add an RTOS configuration file. Point is again the XDCtools boolean switches are not (fully) disabling the WiFiCC3100 module from the EK_TM4C1294XL.c build. There are actually 3 more middle ware Symbol warnings if we don't disable all the middle ware switches in the RTOS configuration file.

The other RTOS project that builds successfully actually disables WiFiCC3100 middleware Symbols, developed upon an REX example project 2.16.0.08. Oddly XDCtools v2.50.3.33 build complains of TI platforms no longer being shipped part of packages.  Yet the TM4C1294KCPDT target platform is already part of the project properties, searching  for platform does not help. The only way project builds is with XDCtools v3.32.2.25 or previous.

Discovered difference between the two RTOS project is (rtos_empty) adds ${PROJECT_ROOT} include path, below compiles path:

C:/CCS7v3/ccsv7/tools/compiler/ti-cgt-arm_16.12.0.STS/include
${PROJECT_ROOT}

Moving (Project_Root) variable above compiler path fixed issue of WiFiCC3100 Symbols errors. The other RTOS project does not have ${PROJECT_ROOT} nor a DOS style compiler include path rather uses ${CG_TOOL_ROOT}/include. The compiler was touching the WiFiCC3100 function (EK_TM4C1294XL.c) when the (rtos_empty.cfg) XDCpackage Boolean switches for the platform should not assert as active since the middle ware is not installed.

Agree compile failure was not an XDCtools version issue. Oddly recall the same WiFi Symbols errors with UARTIdleLogger imported example project.  Yet none of that has anything to do with the TI-RTOS repository path variable being placed in the XDCtools properties then lists (all) the available products.

Otherwise TI-RTOS don't show up simply after being selected CCS general products tab and list don't update via refreshing. We have to close CCS7.3 reopen for any RTOS selections to be listed in the available products as such. Otherwise all that shows up are XDCtools grey icon. Imported RTOS examples are not configuring the platform in all cases or the download RTOS 2.16.01.14 was mangled yet still installed? Manually adding ${COM_TI_RTSC_TIRTOSTIVAC_REPOS} variable under XDCtools repositories, the Available list then has TI-RTOS,UIA selections. Question is why is REPOS variable missing from imported RTOS later projects builds.

ToddMullanix said:

Then can you detail exactly any changes you make to the project to reproduce the greyed out items or the above picture.

They are not greyed out and do function quite well as explained above post simply add the TI-RTOS repository variable to XCDtools properties in the project. The REPOS variable is missing in the drop down list of both RTOS version UARTIdleLogger, rtos_empty examples or perhaps compiler. The available products is not added by default it is an IDE tool view taken from other, drop down selections list.

ToddMullanix said:

3. Graphically edit the .cfg file.

Please explain what you mean, select the TI-RTOS tab? Seem to recall seeing available list long ago after TI-RTOS was added to a SYSBIOS configuration. When trying to add TI-RTOS object to UARTIdleLogger RTOS configuration a warning message is displayed, that it has no function yet propagated the name TI-RTOS to the top of the outline list.

Can't import any projects from local RTOS install other than GRlib or Examples folder, all other projects produce error shown below. Oddly file import project from tool bar File or archive feature is the only way to import the projects into project tree. Notice there are very few EK_TM4C129XL_TI projects in the list and many GNU for the XL launch pad, seems even odder.

 Imported Watchdog project using the project import from file on tool bar and the available products pane is blank opening Watchdog.cfg file, project properties are missing. 

There is something wrong with your install. If you cannot successful import the empty example, I'm not surprised things are messed up. Can you please uninstall the TI-RTOS and XDCtools versions you are using.

Then delete them from the disk. Then, with CCS closed, install both products again. Start CCS and select ok to install the two new products (then restart CCS). Then try to install empty from Resource Explorer Classic. Does that example import without errors. Does it build? If it does, put the entire build log in a file and attach it. Do not modify the project in anyway before you try to build it. 

Todd

Ok will do a reinstall as you indicated above.

BTW installed rtos_empty project from TI-RTOS 2.16.0.08 and still don't see the new 2.16.01.14 examples projects folder in the REX tree, do you? Do you think I should not see these grey icons, they were put there with the earlier project imports from c:\ti\tirex-content\TI-RTOS 2.16.0.08.... . I just recently installed the 2.16.01.14 using a downloaded windows installer package after installing CCS7.3 two weeks ago.

You do know you can hide repositories in the available products tree options then TI-RTOS 2.16.01.14 folder goes away.

BP101 said:

BTW installed rtos_empty project from TI-RTOS 2.16.0.08 and still don't see the new 2.16.01.14 examples projects folder in the REX tree, do you?

What does this mean? The two release are separate stand-alone products. Did you install them on top of each other?

ToddMullanix said:

You cannot have a project reference both releases

Project properties will not allow that to even take place if a user attempts to do so. Wonder if this issue has more to do with not having both versions of RTOS installed under C:\ti\..etc which is a path far from CCS7 import wizard and project compiler. The installed RTOS packages 2.16.1.14 exist above the IDE folder search path of compiler (lib/libca.a). That always seemed a bit upside down but simply figured the Eclipse IDE could better resolve the RTOS packages path being even closer to CCS7 IDE.

ToddMullanix said:

Then in Resource Explorer Classic (which only looks on your local machine) import driver/empty

Behooves me why anyone would go backwards (Classic REX) after using the REX cloud explorer in even older versions of RTOS to import example projects into CCS7.0

The same 3 grey icons are part of the empty project configuration file, yet the XDCtools includes paths appear somewhat different. Seems Classic REX is a WA, TI made a U turn in a no U turn restricted zone. lol

--xdcpath="C:/CCS7v3/tirtos_tivac_2_16_01_14/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/tidrivers_tivac_2_16_01_13/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/ndk_2_25_00_09/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/uia_2_00_05_50/packages;C:/CCS7v3/tirtos_tivac_2_16_01_14/products/ns_1_11_00_10/packages;C:/CCS7v3/ccsv7/ccs_base;" xdc.tools.configuro -o configPkg -t ti.targets.arm.elf.M4F -p ti.platforms.tiva:TM4C1294NCPDT -r release -c "C:/CCS7v3/ccsv7/tools/compiler/ti-cgt-arm_17.9.0.STS" --compileOptions "-mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path=\"C:/Users/Documents/CCS7_Workspace/empty_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT\" --include_path=\"C:/Users/Documents/CCS7_Workspace/empty_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT\" --include_path=\"C:/CCS7v3/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b\" --include_path=\"C:/CCS7v3/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31/packages/ti/sysbios/posix\" --include_path=\"C:/CCS7v3/ccsv7/tools/compiler/ti-cgt-arm_17.9.0.STS/include\" --define=ccs=\"ccs\" --define=PART_TM4C1294NCPDT --define=ccs --define=TIVAWARE -g --gcc --diag_warning=225 --diag_warning=255 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi  "