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.

LAUNCHXL-CC1310: sensor controller

Part Number: LAUNCHXL-CC1310

Hi team,

Here's an issue from the customer may need your help:

Pins used under the sensor controller cannot be used in the main reference program.  Thanks.

Best Regards,

Cherry

  • Hi Cherry,

    I need a bit more context to support on this. Could you provide more information on the project and what the specific issue/question is?

    In general terms the pins that are used by the sensor controller should not be used my the application running on the CPU. 

    Regards,

    Fausto

  • Hi Fausto,

    Thanks for your support and the original case has been resolved, but the customer still has a question:

    Why would the "applications get system runtime" and the "software controller run program" conflict and cause a restart? 

    Thanks and regards,

    Cherry

  • Hi Cherry,

    what are you referring to with "applications get system runtime" and the "software controller run program"? Sorry but without any context is hard to reply to the customer question.

    Regards,

    Fausto

  • Hi Fausto,

    I'm trying my best to understand what the customer is saying and just got some clarification as follows:

    -software controller run program: an interrupt from the sensor controller wakes up the application and then uses the application

    -applications get system runtime: Clock_getTicks() to get the system runtime.

    Please ley me know if it helps.

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Is the client saying that the application running on the MCU wakes up due to a sensor controller interrupt and as soon as it calls Clock_getTicks() the system resets? This sound very strange to me. I don't have enough details on the costumer use case to suggest a potential problem though. If they could provide a minimal application in which they can show this issue we can help debug. But with so little information is hard to pin point the source of the problem.

    Regards,

    Fausto

  • Hi Fausto,

    If they could provide a minimal application in which they can show this issue we can help debug.

    Please see the original application:

    timer0Start(TIMER0_MODE_PERIODICAL, 30000, 1); //2.5ms
    
    //fwGenAlertInterrupt();
    
    //gpioSetOutput(AUXIO_O_LED); //Output high 
    
    //gpioEnableInputBuf(AUXIO_XS_LED1);
    
    //U16 i=0;
    
    //if(state.counter == 0){
    
    // timer0Wait();
    
    // timer0Start(TIMER0_MODE_PERIODICAL, 240, 0); //10us
    
    // for (U16 n = 0; n < 50; n++) { //2ms
    
    // timer0Wait();
    
    // U16 z;
    
    // gpioGetInputValue(AUXIO_XS_LED1;z);
    
    // if(z==1){
    
    // //i=i+1;
    
    // //if(i>5){
    
    // fwGenAlertInterrupt();
    
    // n=50;
    
    // //}
    
    // }
    
    // }
    
    // gpioDisableInputBuf(AUXIO_XS_LED1);
    
    // gpioClearOutput(AUXIO_O_LED); //Output low
    
    //}
    
    //if(state.counter == 0){
    
    // timer0Start(TIMER0_MODE_PERIODICAL, 240, 0); //10us
    
    // for (U16 n = 0; n < 300; n++) { //3ms
    
    // timer0Wait();
    
    // U16 z;
    
    // gpioGetInputValue(AUXIO_XS_LED1;z);
    
    // if(z==1){
    
    // fwGenAlertInterrupt();
    
    // n=300;
    
    // }
    
    // gpioDisableInputBuf(AUXIO_XS_LED1);
    
    // }
    
    //}
    
    //fwScheduleTask(1);

    Thanks and regards,

    Cherry

  • Hi,

    May I know is there any update?

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Sorry for the delay, I have been out of office for the past two weeks without access to email or E2E. 

    I can't immediately see any correlation between the AUX Timer0 used only by the sensor controller and the TIRTOS Clock_getTicks() call that uses the OS internal tick. It would also be important to have a simple costumer application on the MCU side (only the sensor controller code is shared above) that triggers the problem. If they can provide us steps to replicate the issue we can help debug at our best effort.

    I have two addition question:

    - Why is the majority of the code in sensor controller commented out? it is not needed to execute the commented code to trigger the issue?

    - What simplelink SDK version is the costumer using?

    Regards,

    Fausto

  • Hi Fausto,

    Thanks and this issue has been resolved by the customer. Thanks!

    Regards,

    Cherry

  • Thank you for the update Cherry.

    Regards,

    Fausto