CC2640/CC2650 missed semaphore causes task to remain blocked

Hi Eirik,

I tried two versions of semaphore. The first is using the semaphore/queue as it is shown in the SimpleBLEPeripheral example. The Sensor Controller and each sensor's hwi enqueues a msg as in

SensorDriver_enqueueMsg(SD_CHAR_CHANGE_EVT, paramID);

In my second version I use only a counting semaphore (and no queue). Each sensor sets a flag and posts the semaphore as in

// Store the event.
events |= SD_SC_EVT;
// Wake up the application.
Semaphore_post(sem);

Both versions have the missed semaphore issue for any given sensor at any random time. The hwi for the Sensor Controller is:

static void SensorDriver_scAlertCallback(void)
{
	// FIXME
	scifClearAlertIntSource();
	scifAckAlertEvents();

//  // Store the event.
//  events |= SD_SC_EVT;
//
//  // Wake up the application.
//  Semaphore_post(sem);
	SensorDriver_charValueChangeCB(TIADS1298DATAREADY);   // enqueue msg
} // scTaskAlertCallback

Is the default semaphore type in SimpleBLEPeripheral binary? I see the following code:

static ICall_Semaphore sem;
ICall_registerApp(&selfEntity, &sem);

but nothing explicitly to initialize it like:

Semaphore_Params semParams;
Semaphore_Params_init(&semParams);
semParams.mode = Semaphore_Mode_COUNTING;
Semaphore_construct(&semScTaskAlert, 0, &semParams);

Thanks for your help on this.

Hi Eirik,

I verified the task is not running or stuck. The task would un-light the respective LED for the sensor whose hwi triggered a semaphore post, but the LED remains lit. The same task processes reads from other sensors and their LEDs toggle, so the task is not stuck, but the sensor who's interrupt was not serviced remains in a non-responsive state since its interrupt register is never cleared by the task.

Could this be a race condition on setting and clearing bits in the events variable?  If you set and clear separate variables to flag these events does that fix things?

Hello Casey,

The application must ensure that a tickPeriod is not too short for the Sensor Controller to complete its tasks within a single tick interval. The tick period is set when you call the scifStartRtcTicksNow() function. The actual sensor controller framework code will start by clearing the RTC Channel 2 wake up event upon wakeup and wait for it to be cleared during powerdown before setting the clear bit in WUEVCLR back to 0. 

From C:\Program Files (x86)\Texas Instruments\Sensor Controller Studio\fw_templates\framework_template.asm:

                       ; Wait for the ACK event to be cleared
/waitOnRtcClearing:    iobtst      #IOB_WUC_WUEV_RTC, [#IOP_WUC_WUEVFLAGS]
                       biob1       /waitOnRtcClearing
                       iobclr      #IOB_WUC_WUEV_RTC, [#IOP_WUC_WUEVCLR]

I believe you can get stuck here forever.

Thanks for the inputs from everyone!

To clarify Casey's post,  I have two separate (or perhaps the same issue): one is some kind of system lockup (per this forum thread); the second is a "missed semaphore" issue which this forum thread is addressing.

In my firmware, I have a single task that does sensor reads (either using MCU's I2C, SPI, GPIO (bit-bang SPI). The Sensor Controller is also used to read data from a sensor. The task is awoken with a semaphore queue (similar to that in SimpleBLEPeripheral) with a parameter identifying which sensor is to be read. My thought is that since I'm using a single task with a sempahore queue, then whenever a sensor has data ready to be read, it will wake up the task (if the task is not already reading another sensor's data) and then read the data. If another sensor is in the process of having its data read, then this new sensor will simply wait until its semaphore gets processed. 

In the sensor HWI, I only call 

PINCC26XX_setOutputValue(Board_AIN1, Board_LED_ON);
SensorDriver_enqueueMsg(SD_CHAR_CHANGE_EVT, paramID); 

to verify with an LED that the HWI occured. In the task code for the specific sensor, I clear the LED and read the sensor's data. When the system fails, I see the remain LED lit, implying that the semaphore was posted but not serviced.

I tried various combinations of sensors (there are three in my system), and only running 1 at a time does not show this missed sempahore issue. I don't think it's an issue with the Sensor Controllers tickPeriod since it runs fine by itself, and also if I simply disable the sensor control and just run the other two sensors on their HWIs, the system issues still occur. Also, disabling the bit banged sensor doesn't help, so I don't think it's an issue with the bit banging driver.

Thanks again for everyone's advice; I appreciate the inputs, and hopefully can narrow down and resolve this soon.