• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 174 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BOOSTXL-CC2650MA: Icall_abort assert when calling SerialPortService_SetParameter() in custom task

James Morris
Prodigy 60 points
Part Number: BOOSTXL-CC2650MA
Other Parts Discussed in Thread: CC2650

CCS: 10.4

XDC: tirtos_cc13xx_cc26xx_2_20_01_08

SDK: ble_sdk_2_02_01_18

Compiler: ti-cgt-arm_5.2.6

I'm (still) working with the updated serial port profile example from Github, and I'm basically modifying it to have a layer of behavior between the UART and BLE interfaces.  In the example's original behavior, a character received on the UART is passed to BLE via a call to SerialPortService_SetParameter().

If I try to write to the attribute in the same way, from another task, this call ultimately results in a call to Icall_abort(), and an assert spinlock.  While I'm trying to develop for the BOOSTXL-C2650MA, I've also configured and compiled for CC2650_LAUNCHXL and run on the launchpad (the project's original configuration), with the same result.  The best I've been able to determine is that I think Icall_abort() is being called from the stack, but it's not clear to me how to debug there.

I have produced a simplified project with a task which simply iterates through each letter of the alphabet once per second, and consistently reproduces the issue.  I will attach the archive to this ticket if possible.

  • 0
    Prodigy 60 points

    Sorry; XDC tools are: xdctools_3_32_00_06_core, but that is the TI-RTOS version in the original post.

  • 0 in reply to James Morris
    TI__Mastermind 27680 points

    Hi James,

    Are you able to set breakpoints, toggle GPIO's/LED's or modify state variables to isolate the call to Icall_abort()? This is how I would initially approach the problem to isolate the issue.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 60 points

    I wasn't able to find an instance of Icall_abort() that triggered a breakpoint in the app project; hence my supposition that it's occuring in the stack project. I think I tried debugging the stack project, but that prevented the application from running correctly.  Toggling an LED should be my next strategy.

    It did occur to me that I didn't register the task with Icall (this is the case in my attached archive, too), but when I tried, I just found myself in some kind of app_exit function.

    What I just realized is that I was registering the functions in a different initialization function, and perhaps I should be doing that within the actual task, before the infinite loop.  If a function that calls ICall_registerApp() exits, what happens?

  • +1 in reply to James Morris
    TI__Mastermind 27680 points

    Hi James,

    I'm glad you're able to make some progress!

    I'd also recommend following the steps in this guide for developing tasks for your application as another resource.

    https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_3_10_00_15/docs/blestack/ble_user_guide/html/ble-stack-3.x/creating-a-custom-bluetooth-low-energy-application.html#creating-additional-icall-enabled-tasks\

    James Morris said:
    If a function that calls ICall_registerApp() exits, what happens?

    I don't have the answer to this now, but I will ask internally to see.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 60 points

    The good news is that in my attached project, it behaved as expected when I added ICall registration at the top of the task function, and incremented ICALL_MAX_NUM_TASKS, ICALL_MAX_NUM_ENTITIES, and OSAL_MAX_NUM_PROXY_TASKS as directed in the link you provided. Note: contrary to the warning on that page, ICALL_MAX_NUM_TASKS did not equal (OSAL_MAX_NUM_PROXY_TASKS + 1) before or after the increment, but it did not abort as a result (though perhaps it's not supposed to -- the wording is a bit ambiguous).

    However, upon applying this to my main project, the project resurfaced an issue I thought I'd addressed when the linker failed to resolve three functions in an application source file that contains the additional task I wish to add.  Each is loosely associated with ICall in some way, but not consistently so.  Probably a different issue for a different ticket.

  • 0 in reply to James Morris
    TI__Mastermind 27680 points

    Sounds good. Yes I would open a different ticket for a different issue.

    Additionally, the answer I got to "What happens when a function that calls ICall_registerApp() exits internally" was "It's either successful, or there is not enough resources to register the application. It would move on, but if you don't have any resources, you would want to catch that before moving on really."