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.

RTOS/LAUNCHXL-CC1350: Possible PIN driver bug

Part Number: LAUNCHXL-CC1350

Tool/software: TI-RTOS

Hello:

I have an app that has two clocks and a task. One clock posts to a semaphore, which the task is waiting on, with the intent of inverting an LED on/off state. The second is a clock with a callback function, which also inverts the on/off state of different, on-board LEDs. Both of these two sections of code use the PIN driver, but with different PIN_State parameters. The task has its PIN_State as a local variable to the task function, whereas the clock callbacks reference a global variable. PIN_Open for the task occurs within the task, while PIN_open for the clock callbacks happen prior to creation of the clocks in main.

I gather from the documentation that the PIN driver is supposed to provide a mutual exclusive lock on the assigned PINs. Yet, when the clock callbacks attempt to utilize the PIN driver, no LEDs are working whereas if I disable those calls within the clock callbacks, I see that the offboard LED lights as it should (i.e. the PIN driver calls within the task begin to work again).

I'm guessing the response to this will somehow be related to this executing in the context of an SWI, but this seems like a bug to me. Even if the code in the callback was to somehow fail to execute, I expected the code in the task to continue to work due to it's exclusive context. As it stands, it seems to me that in order to get this to work, I might have to create a separate task altogether for the other LEDs or use a sort of flag that the callbacks modify and use as an event loop of some sort within the existing task to manipulate the LEDs separately. Either approach seems more complicated to me than it should be.

Regards,

Michael

  • As another consideration,

    If I use the GPIO driver ( which doesn't work for me for anything besides the onboard RLED and GLED ) within the clock callbacks, then everything works fine...the task LED controlled by the PIN driver flashes as do the ones controlled by the clock callback using the GPIO driver.
  • Hi Michael,

    Could you share a example of your code that I could review?

    The GPIO driver typically do not perform any argument checks, but blindly perform GPIO operation with the assumption that everything is setup. Under the hood, the GPIO driver actually wraps the PIN driver but with a few custom implementations for things like setting and reading PIN values.

    You could try to use PINCC26XX_setOutputValue(pinId, val) instead of PIN_setOutputValue(PIN_Handle handle, PIN_Id pinId, uint32_t val) and see if it makes a difference. This is basically writing to the output register without any checks of the arguments.
  • I don't think I have that code anymore...my code base no longer reflects this issue. After thinking about it for a bit, I think perhaps what was happening is that my code was failing some assert in the library code and going into an infinite loop. I have seen that in the example code and the theory fits the facts. For now though, I think I can close this issue because it no longer impacts me.