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.

AM2432: [Question] Duplicate networking source and library definitions in SDK – What is the correct usage?

Part Number: AM2432

Tool/software:

We are currently using INDUSTRIAL_COMMUNICATIONS_SDK_AM243X 11.00.00.08, and we noticed that the SDK contains two parallel sets of source code and libraries under the following directories:

/source/networking/...  
/mcu_plus_sdk/source/networking/...

For example, both of the following exist:

  • /source/networking/icss_emac
  • /mcu_plus_sdk/source/networking/icss_emac

Likewise for icss_timesync.

Additionally, prebuilt libraries are provided under both trees:

/source/networking/icss_emac/lib/...
/mcu_plus_sdk/source/networking/icss_emac/lib/...

■ Questions

  1. What is the intended usage model?
    Are users expected to choose one of these two trees?
    Or is there a reason both exist, and we should mix and match under certain conditions?
  2. Which version (under /source or /mcu_plus_sdk/source) is meant to be used in production with the prebuilt libraries such as:
    • icss_emac.am243x.r5f.ti-arm-clang.release.lib
    • icss_timesync.am243x.r5f.ti-arm-clang.release.lib
  3. How should we configure the include paths and library paths in our projects to avoid accidental mixing?
    Should we exclude one tree entirely?
    Is there any official guidance on this?
  4. Will future SDK releases consolidate these structures or clarify their intended use?

■ Context: Problem we encountered

In our project, we linked the following libraries:

${INDUSTRIAL_COMMUNICATIONS_SDK_PATH}/source/networking/icss_emac/lib/icss_emac.am243x.r5f.ti-arm-clang.release.lib  
${INDUSTRIAL_COMMUNICATIONS_SDK_PATH}/source/networking/icss_timesync/lib/icss_timesync.am243x.r5f.ti-arm-clang.release.lib

And we set both of the following include paths:

${INDUSTRIAL_COMMUNICATIONS_SDK_PATH}/mcu_plus_sdk/source  
${INDUSTRIAL_COMMUNICATIONS_SDK_PATH}/source

As a result, the compiler picked up an unintended version of icss_timeSyncApi.h (from /msu_plus_sdk/source/), leading to a mismatch in the TimeSync_Config_t structure. This caused memory corruption at runtime.

The issue was resolved by changing the include path order, but this revealed a deeper concern: how can we be sure which source tree matches the library binaries?

Any clarification or guidance would be highly appreciated. We would like to align our project with the SDK’s intended structure and avoid fragile or inconsistent configurations.

  • Hi,

    Thanks for the detailed thread and bringing this into our attention.

    For AM243x, the initial plan was to move the ICSS Networking components exclusively to MCU+ SDK, however post-release fixes required maintaining ICSS_EMAC and TimeSync in the Industrial Comms SDK as well.


    To answer your questions:

    What is the intended usage model?

    For AM243x, all Industrial Protocol examples in the Industrial Comms SDK should use ICSS EMAC/TimeSync from the Industrial Comms SDK.

    The ICSS_EMAC/TimeSync components in MCU+ SDK remain effectively unused.

    Which version (under /source or /mcu_plus_sdk/source) is meant to be used in production with the prebuilt libraries such as:
    • icss_emac.am243x.r5f.ti-arm-clang.release.lib
    • icss_timesync.am243x.r5f.ti-arm-clang.release.lib

    You should use the libraries under INDUSTRIAL_COMMS_SDK_INSTALL_PATH/source/networking.

    How should we configure the include paths and library paths in our projects to avoid accidental mixing?
    Should we exclude one tree entirely?
    Is there any official guidance on this?

    You should use the files under INDUSTRIAL_COMMS_SDK_INSTALL_PATH/source/networking.

    There's no generic approach to handle this, but you can remove the sources and clean the ICSS EMAC and TimeSync libraries under INDUSTRIAL_COMMS_SDK_INSTALL_PATH/mcu_plus_sdk/source/networking -> This would ensure that you at least get compilation failures in case of incorrect include path.

    Will future SDK releases consolidate these structures or clarify their intended use?

    Yes, we are planning to remove the duplication of the ICSS networking components between Industrial Comms SDK and MCU+ SDK in the future releases. But we'll document this in our SDK docs.

    Regards
    Archit