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.

CC2650 simultaneous hwi

Expert 1340 points

Other Parts Discussed in Thread: CC2640

I have a system with multiple asynchronous sensors. The sensors set different CC2640 GPIO pins low when data is ready. I'm using hwi to post semaphores to a thread (lower than the ICall_createRemoteTasks() and GAPRole_createTask() priorities) to read sensor data (via I2C/SPI) upon these pins' falling edge. It seems that occasionally I miss a hwi (since that sensor's data ready pin stays low;  the sensor clears the pin if data is read) if another hwi is already running. How can I nest these hwi? Or is there another solution to this problem? Thanks!

  • Hello Tosa,

    Is it that you miss the processing of the HWI's SEM post due to multiple interrupts occurring before your task can read the sensor, or do you actually miss the HWI itself?

    If it's the former, maybe you can use the Event module in the TI-RTOS to queue up the HWI notification in lieu of a semaphore? Can you share how you are constructing your HWIs to the various GPIOs?

    Best wishes
  • Hi JXS,

    The issue is due to missing the hwi interrupt itself, because it seems that occasionally two sensors assert their data ready pin almost simultaneously. I set the hwi as follows:

    init()
    {
    PIN_open(&pinHandle, aPinListHui); PIN_registerIntCb(&pinHandle, sensor_irq); PIN_setInterrupt(&pinHandle, Board_INT | PIN_IRQ_NEGEDGE);
    ...
    }
    void sensor_irq(PIN_Handle hPin, PIN_Id pinId)
    {
    	(*ServiceCB)(DATAREADY);
    }

    Thanks for your assistance!

  • Hi Tosa,

    How are you verifying that you are missing the HWI? Do you miss any HWI's if you are only enabling the interrupts for one sensor?
  • Hi Sean,

    Actually I have not verified this is the problem. Do interrupts get disabled when a hwi is in progress? If so, then this is a reasonable possibility of the issue. The issue is not due to multiple SEMs being posted (for a single sensor) before I can read the data since the interrupts occur at long intervals (4ms for one sensor; 49ms for another; 24ms for a third) so there's plenty of CPU time in between sensor interrupts. Also, I haven't noticed missing interrupts if I run only one sensor. Thanks!
  • Hi Tosa,

    The PIN driver (ti/drivers/pin/PINCC26XX.c) in the 2.1 SDK will do the following:

    PIN_Isr is executed when a edge detect event occurs. It will clear the event corresponding to only this IO, check if a callback is registered with this IO and execute the callback. The interrupt source from the GPIO module is an OR of all the edge detect events in the GPIO module.

    The ISR will also unpend the interrupt going to the CPU for some reason though that is not necessary since this is done automatically by the CPU by entering the interrupt. Clearing it should not cause any lost interrupts though as the interrupt source (GPIO module edge detect output) will still remain high when you exit the interrupt, causing the interrupt to become pending again.

    Interrupts do not get disabled when a HWI is in progress but all peripheral drivers use the same priority so other interrupts will remain pending until you exit this interrupt (the only exception is the RF interrupts which have higher priority)

    The simplest way to check whether you have interrupts missing or not would be to connect the same input to two different IO's so the interrupt occurs at the exact same time.

    Regards,
    Svend
  • Hi Svend, 

    Thanks for your post; I'm back on this issue. I haven't yet done the experiment you suggested, but is it possible to set interrupts based on pin levels rather than edge? That might mitigate the issue (barring that it doesn't bring new ones...)

    Thanks!

  • Hi Svend,

    I did a simple test as you suggested, by connecting a button to two GPIOs with their own interrupt handlers that toggle LEDs. The LEDs for both interrupts do toggle, suggesting that there is no issue with simultaneous hwi. There is some other issue as to why the sensor data is not always read. Thanks!