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.

CC3230SF: CC3230 ISR issue

Part Number: CC3230SF

Hello,

I am using CC3230 SoC for one of my projects. The SoC's reset is controlled through MSP430 MCU. I have a push button switch which is read on MSP430 MCU. When the switch is detected, MSP430 sends data to CC3230 over UART and then CC3230 glows the LEDs. We have observed that the when switch is pressed for the first time, device does not give any response but when it is pressed second time, the device gives response. We have checked for the data transmitted over UART and it is fine. 

We are suspecting that there is some issue happening at the ISR handling. This is happening for few devices and not for all the devices. 

Any idea what is causing issue?

Appreciate your help. 

Thanks. 

  • Have you ensured the pins are set correctly in syscfg?

    How have you set the interrupt for UART? What if you used a polling method? 

  • Because only a few devices have this error, ensure the issue is not hardware related. Make sure soldering is good with the pins in question. 

  • Hi Sabeeh,

    Thanks for reply. 

    I will check this and let you know. 

    In the meantime, we also found that after CC3230 is wake up from shutdown mode, it takes different time spans for GPIO initialization. Somewhere we have found that the time is 1.7sec and somewhere it is 1.5 sec and so on. 

    Can you please let me know can there be a piece to piece variation in SoC?

    Thank you. 

  • How are you measuring the timing for GPIO initialization for wakeup? Could you please post some code that performs this?

  • Hi, 

    We have measured the time on scope, between CC wakeup and the GPIO initilization. 

    I have attached the part of code here. 

    main_Thread.txt
    void *mainThread(void *arg0)
    {
        pthread_attr_t pthreadAttrs;
        pthread_t slThread;
        pthread_t azureThread;
    
        int status;
        _i16 Status;
        _u8 persistent = 1;
       Board_init();
        GPIO_init();
    
        SPI_init();
        Init_Timer();
        Init_Timer1();
        Init_Timer2();
        Init_PWM();
    #if MAIN_DBG_MODE
        Display_init();
              /* Open the Display for output */
        display = Display_open(Display_Type_UART, NULL);
        if (display == NULL)
        {
            /* Failed to open the Display driver */
            Display_printf(display, 0, 0, "Failed to open the Display driver %d",display);
            while (1);
        }
    #endif
        Network_init();
        MCU_Init();
        Status = sl_DeviceSet(SL_DEVICE_GENERAL, SL_DEVICE_GENERAL_PERSISTENT, sizeof(_u8), (_u8*) (&persistent));
        if( Status )
        {
        /* error */
        }
    
        /* Configure the LED and button pins */
        GPIO_setConfig(TEST_PIN, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);
        GPIO_write(TEST_PIN, LED_OFF);

  • Some variation would be expected, however this seems a little large. Could you please check your other parts (like resistors and capacitors) and ensure that those tolerances are small? If you have large tolerances in DC filtering capacitors, then that would explain delay variations. 

  • Hi, 

    Yes I will check this for sure. 

    Also would like you to know that we have ran TI application code on the board also and got the similar results. 

    So the firmware seems to be okay. I will check for the part tolerance and let you know. 

    Thanks.