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.

CC2640R2F-Q1: Sensor Controller - control of Tasks

Part Number: CC2640R2F-Q1
Other Parts Discussed in Thread: CC2640

Dear colleagues,

I'm trying in CC2640 implement parity detecion(NACK signal) acc. ISO7816-3.  Short introduction. When SIM card send character,where parity bit is corrupted,receiver(in this case MCU) must pull UART line to ground after time 10.5 bit from start of bit for 1-2 bit time.  I developed this using sensor controller. I can achieve  good baudrate(up 400kbits) . I'm polling state of bits and I calculate parity bit. I'm happy from this. But I have little problem with control of this Task.  In Aplication I call:

scifOsalInit();
scifInit(&scifDriverSetup);

scifSwTriggerExecutionCodeNbl(BV(0));

For waiting start bit I used  function fwWaitForEvSignal().Thanks for this I have constanty small latency. But big disadvantage is, that I have no possibility kill this task.And I have no full control, what sensor controller do.currently . When I want end of task, I 'm using special input variable presc. But I have to wait to next failing edge on the UART.

Do You know, how I can kill such task earlier? scifUninit?

In my case scifOsalInit() is needed? When I'm not using task scheduler.

My sensor controller code:

U16 stateRx = 0;
U16 i = 0;
U16 parity = 0;
U16 work = 1;
while(work == 1){
    i = 0;
    parity = 0;
    fwWaitForEvSignal(FW_WAIT_SIGNAL_AUXIO_BASE+AUXIO_I_RX,0);
    timer0Start(TIMER0_MODE_SINGLE,input.NACKdelay-25,0);
    if(input.presc == 0){
        
        timer1Start(TIMER1_MODE_SINGLE,input.delay-55,0);
        timer1Wait();
        timer1Start(TIMER1_MODE_SINGLE,input.halfBitDelay,0);
        timer1Wait();
        
        while(i<8){
            gpioGetInputValue(AUXIO_I_RX;stateRx);
            parity ^= stateRx;
            timer1Start(TIMER1_MODE_SINGLE,input.delay-47,0);
            timer1Wait();
            i = i+1;
        }
        //Parity bit
        gpioGetInputValue(AUXIO_I_RX;stateRx);
        parity ^= stateRx;
        output.NACK = 0;
        
        timer0Wait();
        if(parity == 1){
            gpioSetOutput(AUXIO_O_ERROR);
            timer1Start(TIMER1_MODE_SINGLE,input.delay-40,0);
            timer1Wait();
            gpioClearOutput(AUXIO_O_ERROR);
            fwWaitForEvSignal(FW_WAIT_SIGNAL_AUXIO_BASE+AUXIO_I_RX,1);
        }else{
            timer1Start(TIMER1_MODE_SINGLE,input.delay-47,0);
            timer1Wait();
            gpioGetInputValue(AUXIO_I_RX;stateRx);
            if(stateRx == 0){
                output.NACK = 1;
            }
            fwWaitForEvSignal(FW_WAIT_SIGNAL_AUXIO_BASE+AUXIO_I_RX,1);
        }else{
        work = 0;
    }
}

  • Hi Pawel,

    Pawel Biela said:
    Do You know, how I can kill such task earlier? scifUninit?

    No, you cannot kill a task being executed. To stop a task you can call scifStopTaskNbl(), which calls the termination code, but it will not execute the termination code before the Execution Code or Event Handler Code is finished. 

    Have you tried implementing you code as Event Handler Code instead of Execution code? If you enable the "GPIO Event Trigger" task resource, you could then use a GPIO pin to trigger your code instead of using the fwWaitForEvSignal fuction. This way you'll be able to stop your task while waiting for a GPIO event. This method will also use less power. 

    Pawel Biela said:
    In my case scifOsalInit() is needed? When I'm not using task scheduler.

    Yes, this is needed for you to use the scifStartTasksNbl, scifStopTasksNbl and scifWaitOnNbl functions.

    I recommend to have a look at the "scif_how_to_use.html"-file which is generated in the source folder of your SCS project. There you'll find more information about how to use the SCIF driver and how to integrate you SC task code into your application code. 

    Best regards
    Simon

  • Hi Simon,

    I fully agree with You. Only question, or latency entry to Event Handler Code will be constant(max tolerance 0.2 time of bit -> ~500ns) and small( max 2us,I need read 1 bit). I'll try and I'll inform You.

  • Hi Pawel,

    If your requirement is 2 us then Event Handler will be too slow as it takes 400-500 us to trigger on CC2640R2. Let me get back to you and see if we can solve this.

    -Simon
  • Hi Simon,

    I'm now testing this and results are good. I have constanty latency 1460 ns, so is enough for me. I plan using sensor controller only in active mode.On standby mode I plan no communicate with SIM card.

    I did this in such way: In initialization code I register event , and in event handler code I register again after each byte.
    But I thought, when I call scifStopTasksNbl(BV(0)); from application I 'll kill task, but it doesn't work.

    I plan now use such sequence.I think, that it will be work. :

    scifSwTriggerEventHandlerCode();
    OS_TaskSleep(10);
    state = scifStopTasksNbl(BV(0));
  • Second idea also don't work.

    I want summary my application.
    1. I'm calling at the begin

    scifOsalInit();
    scifInit(&scifDriverSetup);

    2. I start task, return SUCCESS. In iniitialization code I'm registering GPIO event
    state = scifStartTasksNbl(BV(0));

    3. In Event handler code after each byte I'm register event again.

    4. When I have silence on the UART line, I want end task I tried two ways to end task:
    a) In termination code I inserted evhCancelTrigger(0); and I called scifStopTasksNbl(BV(0));

    b) I added special input variable and I added special code in Event hadler code to not register new event and
    I called ;
    scifSwTriggerEventHandlerCode();
    state = scifStopTasksNbl(BV(0));

    5. I want again restart task,In both cases I have SCIF_ILLEGAL_OPERATION. Flag DirtyTasks is not cleared.
    state = scifStartTasksNbl(BV(0));


    Strange, Do You have some idea?
  • I found issue. It was missing scifResetTaskStructs(BV(0),SCIF_STRUCT_STATE);

    Many Thanks for support.
  • Hi Pawel,

    Good that you solved the issue!

    If the event handler solution is not fast enough for you, we have created a new function called fwWaitForEvSignalOrExitFlag that will support your usecase. The new function works as fwWaitForEvSignal, but can be terminated by an exit signal. I have attached the procedure which will be included in the next SCS release. If you want to try it you'll need to do the following steps:

    1. Copy the attached file into C:\Users\<...>\Documents\Texas Instruments\Sensor Controller Studio\proc_defs.
    2. Restart Sensor Controller Studio.
    3. Enable the "Delay Insertion" resource.

    Call the new procedure in task code, like this:

    fwWaitForEvSignalOrExitFlag(FW_WAIT_SIGNAL_AUXIO_BASE + AUXIO_I_BUTTON, 1, #state.exitFlag, 42);

    In this example the application can set state.exitFlag = 42 to make SCE stop waiting for AUXIO_I_BUTTON == 1.

    The documentation for this new procedure definition will be shown as pop-up documentation in the task code editor, but not in the help viewer.

    Best regards,
    Simonhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/fw_5F00_wait_5F00_for_5F00_ev_5F00_signal_5F00_or_5F00_exit_5F00_flag.prd

  • Hi Simon,

    At the moment speed is enough. I'm testing and I can achieve 400kbits as in previous solution with fwWaitForEvSignal . But Your solution(new function) will be great alternative, when I'll find something wrong. Using events, it seems for me more easily and more control and maybe I'll decrease current consumption in active mode.

    Generally, I'm very happy from this Sensor Controller. First time I see such functionality in MCU. Without this I have not chance implement such customize HW driver in application core.(RTOS,interrupts).To big latency
  • Good to hear you like the Sensor Controller!

    The event handler solution is probably easier to have control over and also the lowest power of the three methods. Note that the new method fwWaitForEvSignalOrExitFlag will consume more power as it's based on polling. Your original solution with fwWaitForEvSignal will halt the SC while waiting for the event signal thus consume very little power, however, the clocks etc. will still be active so it will consume more power than the event handler solution.

    -Simon