• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 182 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2745P10-Q1: CC2745P10-Q1 SDK Update

Takuya Tanigawa
Prodigy 20 points

I'm trying to update from SDK simplelink_lowpower_f3_sdk_9_10_00_83 to simplelink_lowpower_f3_sdk_9_14_02_16.
I checked the differences between SDK simplelink_lowpower_f3_sdk_9_10_00_83 and simplelink_lowpower_f3_sdk_9_14_02_16 and found a difference in the definition value of the part that is enabled depending on the presence or absence of the ICALL_FEATURE_SEPARATE_IMGINFO definition, so I'm investigating this definition.
Therefore, I have one question:
Looking at the description of ICall_createRemoteTasks(), the note states that One remote task shall be created per external image.
I understand that "external image" refers to the execution environment stored externally, but is my understanding correct?
If not, please tell me what "external image" refers to.

Also, if possible, could you please explain how to enable and use ICALL_FEATURE_SEPARATE_IMGINFO and the advantages of using ICALL_FEATURE_SEPARATE_IMGINFO?

  • 0
    TI__Mastermind 41590 points

    Hi there, 


    Can we take a step back and understand how exactly you're trying to port? In general you should not ever need to mess with ICALL_FEATURE_ETC. 

  • 0 in reply to Evan W
    Prodigy 20 points

    We only plan to upgrade the SDK version and do not intend to enable ICALL_FEATURE_SEPARATE_IMGINFO.

    However, we would like to gain a deeper understanding of the differences that come with upgrading the SDK version.

    There are differences in the definition of how ICALL_FEATURE_SEPARATE_IMGINFO is handled when it is enabled between SDK 9.10 and SDK 9.14.

    Therefore, we have investigated ICALL_FEATURE_SEPARATE_IMGINFO.

    We would appreciate your guidance on the following points:

    • What is the purpose of the ICALL_FEATURE_SEPARATE_IMGINFO compilation flag?

    • The description of ICall_createRemoteTasks() mentions "external image." Is it correct to understand "external image" as an execution environment stored externally?

  • 0 in reply to Takuya Tanigawa
    TI__Prodigy 190 points
    Purpose of ICALL_FEATURE_SEPARATE_IMGINFO
    The purpose of this compilation flag is to provide modular flexibility in how the system identifies and loads the different components of your firmware. 
    • Standard Mode (Flag Not Defined): Memory addresses (like ICALL_STACK0_ADDR), task priorities, and stack sizes are hardcoded in a local header file named icall_addrs.h included at build time.
    • Separate Image Info Mode (Flag Defined): Instead of using a header file, these values are treated as external constants (e.g., ICall_imgEntries, ICall_numImages) linked into the image at a later stage. This is often used in advanced configurations where the application and stack might be updated independently or built as separate binary images, allowing the ICall framework to "find" the other components via linked symbols rather than fixed headers. 

    In ICall_createRemoteTasks(), an "external image" refers to a distinct executable entity that exists outside the current calling context but within the same device's memory space. 
    • It refers to a separate software project (typically the BLE Protocol Stack) that has its own entry point, memory boundaries, and execution environment.
    • Because the Application and the Stack are often built as two separate projects, the Application must create a "remote task" to initialize and manage the execution of that "external" Stack image.