• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 51 subscribers
  • Views 293 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.

SIMPLELINK-LOWPOWER-SDK: bleapputil_task.c

Luke
Expert 4115 points
Part Number: SIMPLELINK-LOWPOWER-SDK


Tool/software:

Hi team,

I am looking at the latest version of bleapputil_task.c (sdk_9_11_00_18) and I have some observations and questions.

First, we were advised to use a semaphore at the beginning of the BLEAppUtil_Task() to ensure that osalInitTasks() was completed before allowing the code in BLEAppUtil_Task() to run. I think the reported issue was that the chip would sometimes not start up correctly if we did not. Why has this not been incorporated into the latest SDK? Was another way found to ensure the issue no longer occurs?  

Second, issue EXT_EP-12653 (https://sir.ext.ti.com/jira/browse/EXT_EP-12653) says that it was found in release BLE_LOKI_9_10_00 and was fixed in version BLE_LOKI_9_11_00.  I want to see if the issue exists in the SDK that we are using (8_40_00_61).  From the description I thought the change (fix) might be in BLEAPPUtil_Task() but after comparing that function in SDK 9_10_00_83 and SDK 9_11_00_18, I see no difference.  So where was the change made, I need to find out if it existed in 8_40_00_61?

Third, I noticed that these newer SDKs support the following events that the SDK that we are using did not.  What are these events for? (BLEAPPUTIL_EVT_CS_EVENT_CB, BLEAPPUTIL_EVT_CMS_CONN_UPDATE_CB, BLEAPPUTIL_EVT_CM_REPORT_EVENT_CB, BLEAPPUTIL_EVT_CM_CONN_STATUS_EVENT_CB)

Thank you,
Luke

  • 0
    TI__Genius 15825 points

    Hi Luke,

    Is this for an automotive or industrial application?

    Luke said:
    First, we were advised to use a semaphore at the beginning of the BLEAppUtil_Task() to ensure that osalInitTasks() was completed before allowing the code in BLEAppUtil_Task() to run. I think the reported issue was that the chip would sometimes not start up correctly if we did not. Why has this not been incorporated into the latest SDK? Was another way found to ensure the issue no longer occurs?  

    I have a little background on this issue. So the issue was most likely due to the RNG on the chip, and since the race condition was fixed there, there is no need for the fix in the application layer. 

    Luke said:
    Second, issue EXT_EP-12653 (https://sir.ext.ti.com/jira/browse/EXT_EP-12653) says that it was found in release BLE_LOKI_9_10_00 and was fixed in version BLE_LOKI_9_11_00.  I want to see if the issue exists in the SDK that we are using (8_40_00_61).  From the description I thought the change (fix) might be in BLEAPPUtil_Task() but after comparing that function in SDK 9_10_00_83 and SDK 9_11_00_18, I see no difference.  So where was the change made, I need to find out if it existed in 8_40_00_61?

    No, the change would be in bleapputil_process.c :: bleapputil_processStackEvents(). Chances are that the issue also exists in 8.40. Compare the changes in that file of the latest SDK to that prior SDK and you should see changes.

    Luke said:
    Third, I noticed that these newer SDKs support the following events that the SDK that we are using did not.  What are these events for? (BLEAPPUTIL_EVT_CS_EVENT_CB, BLEAPPUTIL_EVT_CMS_CONN_UPDATE_CB, BLEAPPUTIL_EVT_CM_REPORT_EVENT_CB, BLEAPPUTIL_EVT_CM_CONN_STATUS_EVENT_CB)

    You have a mix of events here:

    BLEAPPUTIL_EVT_CS_EVENT_CB is for Channel Sounding. The other events are for connection monitor. Depending on the use-case, you may never need these events (for instance, if you're not using Channel Sounding or connection monitor role).

    Hope that helps!

    Best,

    Nima Behmanesh