This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220SF-LAUNCHXL: OTA for GCC with customized thermostat app

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, CC3220S

Dear TI,

I am using the thermostat code as reference because of the OTA, MQTT (without AWS though) and provisioning functionality. I integrated my own application inside of it and removed all other code parts (sensors, BLE, touch) but so far I have failed to compile the project succesfuly.

There are basically 2 problems that occur.

(1) My project is GCC based, because my own application was ported from another microcontroller. Normally this is not a problem, but I found out that the OTA folder ( {SIMPLELINK SDK PATH}/source/ti/net/ota ) only contains a CCS example. When I use this example in my project, I get several warnings because the CCS compiler is used instead of GCC. Of course I could try to change the compiler to GCC myself, but my current project has include/linking problems (described as second problem) so I don't want to mix these issues at the same time.

Description	Resource	Path	Location	Type
{SDK ROOT}/source/ti/net/ota/ccs/Release/ota.a(CdnClient.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem
{SDK_ROOT}/source/ti/net/ota/ccs/Release/ota.a(CdnDropboxV2.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem
{SDK_ROOT}/source/ti/net/ota/ccs/Release/ota.a(OtaArchive.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem
{SDK_ROOT}/source/ti/net/ota/ccs/Release/ota.a(OtaHttpClient.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem
{SDK_ROOT}/source/ti/net/ota/ccs/Release/ota.a(OtaJson.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem
{SDK ROOT}/source/ti/net/ota/ccs/Release/ota.a(OtaLib.obj) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail	my_app_CC3220SF_LAUNCHXL_tirtos_gcc		 	C/C++ Problem

(2) The second problem that I have, is that the following errors occur when compiling clock_sync.c from the SDK.

{SDK_ROOT}/source/ti/net/utils/gcc/Release/net_utils.a(clock_sync.obj): In function `ClockSync_mutexLock':
/vagrant/Q1_26_3_2019/sdk_root/source/ti/net/utils/clock_sync.c:113: undefined reference to `MutexP_create'
/vagrant/Q1_26_3_2019/sdk_root/source/ti/net/utils/clock_sync.c:119: undefined reference to `MutexP_lock'
{SDK_ROOT}/source/ti/net/utils/gcc/Release/net_utils.a(clock_sync.obj): In function `ClockSync_mutexUnlock':
/vagrant/Q1_26_3_2019/sdk_root/source/ti/net/utils/clock_sync.c:134: undefined reference to `MutexP_unlock'

I noticed that I I add ${COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR}/kernel/tirtos/packages/ti/dpl/package/lib/lib/dpl_cc32xx/MutexP_tirtos.om4g to the linking path, the errors would disappear. I am, however, slightly confused by all the different types of lib extensions (for example .oem4/.om4g/.orm4  or .aem4/.am4g/.arm4), and the difference between gcc/Release and gcc/Debug links in the SDK. Currently I am just doing it based on trial-and-error, but I would like to understand what I am doing. Furthermore, I have added the more general/'umbrella' library ${COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR}/kernel/tirtos/packages/ti/dpl/lib/dpl_cc32xx.am4g to the project, so I would assume that  would normally include the MutexP functions.

Best regards,
MJ

  • Hi MJ,

    1. What version of the CC32xx SDK are you using? There is a GCC makefile.defs available in the source/ti/net/ota/gcc/Release folder of the latest SDKs.

    2. You're correct, you can link the entire DPL library instead of the individual Mutex package. Many of our SDK examples are built with GCC and tested in CCS with the GNU compiler, so you can check out those to see linked libraries and build configurations (such as examples/rtos/CC3220SF_LAUNCHXL/demos/cloud_ota/tirtos/gcc/cloud_ota_CC3220S_LAUNCHXL_tirtos_gcc.projectspec).

    3. The library extensions for the kernel libraries are based on the compiler. For example:
    .aem4: Cortex-M4 targets (ELF format, little endian, TI compiler)
    .am4g: Cortex-M4 targets (ELF format, little endian, GNU compiler)
    .arm4: Cortex-M4 targets (ELF format, little endian, IAR compiler)

    Best regards,
    Sarah
  • (1) I am using SDK 3_10_00_04. I was able to execute the make after reading Section 2.4.3 of this document: http://www.ti.com/lit/ug/spruex3u/spruex3u.pdf

    (2) I already checked the depencendies of cloud_ota, thermostat app (I changed the ccs dependencies to gcc) and even a few more. However I don't know why the dpl_cc32xx.am4g lib does not fully work. Like I said, I could get it working by adding tirtos/packages/ti/dpl/package/lib/lib/dpl_cc32xx/MutexP_tirtos.om4g. However I am a bit afraid that this might only be a workaround to remove the error, and that I might get weird behavior or so.

    This is my list of library dependencies:

    ${INHERITED_LIBRARIES}
    ti/drivers/net/wifi/slnetif/gcc/Release/slnetifwifi.a
    ti/net/lib/gcc/m4/slnetsock_release.a
    ti/display/lib/display.am4g
    ti/drivers/lib/drivers_cc32xx.am4g
    ti/drivers/net/wifi/gcc/rtos/simplelink.a
    !!!!    tirtos/packages/ti/dpl/lib/dpl_cc32xx.am4g   !!!
    ti/devices/cc32xx/driverlib/gcc/Release/driverlib.a
    ti/net/mqtt/lib/gcc/m4/mqtt_release.a
    ti/grlib/lib/gcc/m4/grlib.a
    ti/net/ota/gcc/Release/ota.a
    ti/utils/json/lib/gcc/m4/json_release.a
    ti/net/atcmd/gcc/Release/atcmd.a
    ti/net/utils/gcc/Release/net_utils.a
    ti/net/sntp/lib/gcc/m4/sntp_release.a
    third_party/spiffs/lib/gcc/m4/spiffs.a
    third_party/fatfs/lib/gcc/m4/fatfs.a
    ${GENERATED_LIBRARIES}
    gcc
    c
    m
    nosys

    With the following search paths:

    ${INHERITED_LIBRARY_PATH}
    ${COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR}/source
    ${COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR}/kernel
    ${COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR}/kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/thumb/v7e-m
    ${CG_TOOL_ROOT}/arm-none-eabi/lib

    (3) Thanks for the explanation. That was my guess already. What about the .oem4/.om4g/.orm4 files? Are these for the different compilers as well? As you can see above, adding the .om4g file helps in my case, so is that GCC as well? It seems that both .om4g and .orm4 seem to work without (additional) warnings or errors.

  • Hi MJ,

    2. Can you try changing the link order of the libraries? Some of them have dependencies on other libraries that are not obvious from the build errors. Specifically try linking net_utils.a before dpl_cc32xx.am4g. That seemed to work on my CCS project.

    3. om4g should be the GNU compiler. I would stick with using that even though another compiler builds.

    Best regards,
    Sarah
  • Thanks. That was indeed the solution. I already thought it would be something like that, but it is quite hard to find the correct order if you are not extremely familiar with the source code.
    The code now compiles and links successfully without the MutexP library.
  • Again I encounter the same problem, but this time with CryptoCC32XX from within the OTA lib (GCC version which I compiled myself manually with make command).

    In function `_BundleCmdFile_Parse':
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x4e): undefined reference to `CryptoCC32XX_init'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x54): undefined reference to `CryptoCC32XX_HmacParams_init'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x62): undefined reference to `CryptoCC32XX_open'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x1d2): undefined reference to `CryptoCC32XX_sign'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x20e): undefined reference to `CryptoCC32XX_sign'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x2e8): undefined reference to `CryptoCC32XX_sign'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x390): undefined reference to `CryptoCC32XX_sign'
    OtaArchive.c:(.text._BundleCmdFile_Parse+0x5a4): undefined reference to `CryptoCC32XX_sign'

    The order above is exactly the same, except for the "ti/net/utils/gcc/Release/net_utils.a" is just above dpl lib now.
    It seems that the CryptoCC32XX should be part of the driverslib. OTA is below the drivers lib, so I don't know why it can't find it.

  • Hi MJ,

    Try putting ota.a above drivers_cc32xx.am4g but after the netsock library. I believe that is where all application libraries using the netsock layer should build. Here is my thermostat project:

    Best regards,

    Sarah