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.

CC3235MODSF: Inconsistent Wake-Up from Hibernate

Part Number: CC3235MODSF
Other Parts Discussed in Thread: CC3235SF

Tool/software:

Dear TI Support Team,

I'm using the CC3235SF and calling MAP_PRCMHibernateCycleTrigger() to enter hibernate mode with the internal RTC.

I've observed rare but unpredictable failures where the device does not wake up from hibernate. Most of the time, it resumes operation as expected, but occasionally it fails to do so without any clear pattern.

The setup appears correct, and I’m performing a clean reboot using the following function:

void RESET_COMPLETE_SOC(void)
{
    int32_t retval;

    retval = SlNetConn_stop(SlNetConnEventHandler);
    LOG_INFO("SlNetConn_stop -> retval : %d", retval);
    sleep(2);

    retval = WIFI_IF_deinit();
    LOG_INFO("WIFI_IF_deinit -> retval : %d", retval);

    sleep(1);
if(retval == 0 )
{ 
MAP_PRCMHibernateCycleTrigger(); 
}

else
{
while(1);//wait for watchdog reset

}

} 

This function shuts down network services and the Wi-Fi interface, adds a short delay, and then calls MAP_PRCMHibernateCycleTrigger().

Could you please advise on:

  • Any known issues or limitations with using only the RTC as a wake-up source?

  • Whether any delays, sequencing, or additional steps are required before calling MAP_PRCMHibernateCycleTrigger()?

  • How to confirm that the hibernate interval is correctly configured and armed?


    Additionally, I have the following hardware-related questions:

    • SOP0 and SOP1 are left not connected (NC).

    • SOP2 is connected to the anode of a diode, with the cathode tied to GND via a 10kΩ resistor, and also connected to the base of a transistor via a 1kΩ resistor.

    Could this SOP configuration have any unintended impact on boot or wake-up behavior?

    Also, UART_RX(used for flashing) is left floating (no pull-up resistor). Could this cause any issues during cold boot or hibernate wake-up?

    Please have a look on below schematic snippet :

                                                    

    Can the following configuration cause any issues even if I call Power_disablePolicy() before vTaskStartScheduler() in main()?

Thank you for your support.

  • Dear TI Support Team,


    Please help me with this issue. I’m using SDK: simplelink_cc32xx_sdk_6_10_00_05. I’m waiting for your reply.

  • Hi TI Support Team,

    Kindly acknowledge this message. Awaiting your response.

  • Dear TI Support Team,

    This is a critical issue for our product, which is already deployed. Please respond as soon as possible — I’m awaiting your reply.

    Thank you.

  • Hi,

    Are you sure that SOP mode 0-1-0 is not used (SOP mode UARTLOAD_FUNCTIONAL_4WJ)? Because SOP mode 0-1-0 and missing pull-up at RX line will exactly explain your situation.

    btw ... I am not a TI employee, and from this reason I don't know why your question was not answered from TI side.

    Jan

  • Hi Jan D,

    Thank you for your input.

    I’m pretty sure I’m not using SOP mode 0-1-0 during normal operation. I only use SOP mode 0-1-0 for image programming via UART.

    Regarding the UART_RX floating line : Unfortunately, this product is already deployed in the field, and I cannot make hardware modifications to add a pull-up at this point.

    If there are any software-level mitigations that can help avoid erratic behavior caused by a floating RX during wake-up from hibernate, I’d really appreciate any suggestions.

  • Hi,

    Hard to say shat is going on at your case, because very deed investigation will be needed especially at hardware side. Have you done EMC testing of your device before deployment? You may to someone from TI can give you some additional advices.

    According my experiences with CC32xx it looks like hardware issue (e.g. issue with reset, issue with power source, etc.). If issue will be with hardware (e.g. missing pull-up at RX line) it is likely there will not be software fix possible.

    At first stage you need to have way to reproduce yours issue with repeatability and after that you can dig into hardware if there is way to fix this behaviour.

    Jan