A common error when calling the Bluetooth API is that the program enters iCall_abort. There are two most common causes for iCall_abort.

• The Bluetooth API is directly called from a custom task
• The Bluetooth API is directly called from an interrupt handler or callback function

To avoid entering iCall_abort, use the BLEAppUtil_invokeFunction function for context switching. The BLEAppUtil_invokeFunction function passes the function pointer of the API to be called into the message queue as an argument. The BLEAppUtil task then reads the message queue and executes the corresponding API.

The following is a typical case where the user creates a new task and calls SimpleGatt_notifyChar4 from the main function (myTaskMain) of the task to send Bluetooth data. In this scenario, the user should use BLEAppUtil_invokeFunction to switch contexts, instead of directly calling SimpleGatt_notifyChar4:

Another point to note when using the BLEAppUtil_invokeFunction function is that its second argument, pData, must point to a memory region allocated by BLEAppUtil_malloc. Do not pass the address of a global variable or a local variable directly. In the example below:

Since the address of pParamUpdateReq is passed directly into BLEAppUtil_invokeFunction, it is highly prone to memory errors upon release (the underlying cause is the specific implementation of malloc when the Memory Advanced feature is enabled), which leads to an entry into Exception_handlerSpin:

The correct calling procedure is: Create a pointer variable, allocate a memory region for it using BLEAppUtil_malloc, and pass the pointer as an argument into BLEAppUtil_invokeFunction. By doing so, it can be released safely.