• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 682 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Missing HWIs when handling several peripherals which call HWI_disable()

Pietro Gonizzi
Intellectual 260 points
Other Parts Discussed in Thread: CC2650

Hi all,


I am using TI-RTOS 2.14.03.28, SmartRfBoard with CC2650 7x7, CCS  6.1.1.00022.

I have two tasks (project name rfEasylinkRx_CC2650): a radio task, which continuously waits for incoming radio packets (I use radio in proprietary mode), and a uart task, which prints debug messages over UART. The uart task has lower priority than the radio task.

I then use a second project (rfEasylinkTx_CC2650) on another smartRfboard which transmits radio packets continuously.

Please see both projects attached.

The radio task gets blocked indefinitely on Semaphore_pend() call inside RF_waitCmd() (I use a led to control the execution since in debug mode everything seems to work fine). This happens at an unpredictable time after the application starts.

The problem does not occur if (1) I remove the UART_write() calls in the uart task, or (2) I move UART_write() calls inside the radio task.

I see that UARTCC26XX_write() has some critical sections which are executed between key = Hwi_disable() and Hwi_restore(key) calls, respectively.

Since the semaphore is posted to the radio task when a HWI is received from the Cortex M0 radio chip, I am afraid the system may miss such HWI while performing one of the critical sections of the UART driver. In such case, infact, HWIs are globally disabled.

As a more general question, is any incoming HWI lost if HWIs are globally disabled? Or is it captured first,  and then scheduled later when interrupts are re-enabled?

Cheers

Pietro


2018.rfEasylinkRx_CC2650.zip7587.rfEasylinkTx_CC2650.zip

  • 0
    TI__Genius 10825 points
    HI Pietro,

    The HWI is disabled in UART_write() to do critical work which takes minimal time. In Cortex-M3 devices, any peripheral interrupt that comes through at this time should be latched and serviced when the HWI is re-enabled again.

    One thing I noticed in your projects is that the RF driver is part of your application. Did you add it to your application or was it part of the example application? When I compared the RF.c with the one provided in ti/drivers/rf/RF.c, there were quite a few differences. I don't have expertise in this RF driver so I am not sure what the changes would do to your application. But to debug, can you add a breakpoint (or blink LED) in the RF code which posts the Semaphore that the RF_waitCmd() is waiting on. This would help us narrow the issue.

    Vikram
  • 0 in reply to Vikram Adiga
    Intellectual 260 points
    Hi Vikram,

    thanks for your help.

    The RF driver was part of the application. It was provided to me by a TI employee and it comes from a TI-RTOS kernel version earlier than 2.14.03.28 (I don't know from which version the RF driver was extracted). Anyway, I have now moved to the updated RF driver provided in ti/drivers/rf/RF.c and I get same behaviour: the radio task gets blocked indefinitely on Semaphore_pend() call inside RF_waitCmd().

    If I remove the UART_write() code in the debug task, everything works fine (that's why I think the problem may not be RF related ).

    As you indicated, I added some blink LEDs in the RF code, one in syncCb() and another one in hwiFxnCpe0Active() functions. When the task gets blocked, no LED blinks and, as expected, the Semaphore that the RF_waitCmd() is waiting on is not posted.

    Any hints?

    Cheers

    Pietro
  • 0 in reply to Pietro Gonizzi
    TI__Genius 10825 points
    Hi Pietro,

    Looks like the callback is not triggering. I am not sure what is causing this. I probably will have to setup your projects on my workstation to reproduce the issue. I will also check with the driver experts for their help.

    A newer version of TI-RTOS (v 2.16.00.08) was released last week. The RF driver has been updated in this release. Can you try with this version and check if the issue still occurs.

    Vikram
  • 0 in reply to Vikram Adiga
    Intellectual 260 points
    Hi Vikram,

    the problem seems to be solved by doing one of the following:
    - trying TI-RTOS (v 2.16.00.08) as you suggest
    - keeping the initial setup (TI-RTOS v 2.14.03.28) and changing pktConf.endType from 0 to 1 of RF_cmdPropRx command in smartrf_settings.c. I am in contact with the TI employee who follows my company to debug the situation.

    Thanks for your support

    Pietro
  • 0 in reply to Pietro Gonizzi
    TI__Genius 10825 points
    Hi Pietro,

    Glad the issue was resolved. Can you please mark this thread answered?

    Thanks,
    Vikram