CC2340R5: Wakeup from shutdown doesn't happen when SPI chip-select and two other GPIO pins are used as wakeup lines

Followup information:

MCU: CC2340R5-RGE with our custom PCB
DIO11: SPI chip select
DIO8: Button1 /w internal pull-up
DIO20: Button 2 /w internal pull-up

Hello Jaimin,

I hope you are doing well. I wanted to ask which SDK version this is on, and which chip select type you have enabled. 

• Hardware chip select No additional action by the application is required.
• Software chip select The application needs to handle the chip select assertion and de-assertion for the proper SPI peripheral 

Thanks,
Alex F

I was using SDK v7.40 when I posted this query. For the sake of ruling out SDK version I repeated this activity with v9.11.00.18. I see same behaviour seen in waveforms.

I have used Hardware based chip-select. Please find my sysconfig attached for you reference.
/cfs-file/__key/communityserver-discussions-components-files/538/basic_5F00_ble.syscfg.zip

Hello Ajmeri Jaimin,

I performed some tests today with the code below, trying to replicate the issue you found with setting SPI chip select to wakeup (or commenting it out); in my tests I did not notice the same behavior as the device could wakeup from the button press in either case (with or without SPI CS). Could you try the code below on your custom device to see if you get similar results? 

#define CONFIG_SPI_CONTROLLER           0
/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{
    PowerLPF3_ResetReason resetReason = PowerLPF3_getResetReason();

    /* If we are waking up from shutdown, we do something extra. */
    if (resetReason == PowerLPF3_RESET_SHUTDOWN_IO)
    {
        /* Application code must always disable the IO latches when coming out of shutdown */
        PowerLPF3_releaseLatches();

    }
    SPI_Handle spi_handle;
    SPI_Params spiParams;
    SPI_Transaction transaction;
    uint32_t i;
    bool transferOK;
    int32_t status;
    /* 1 second delay */
    uint32_t time = 1;
    SPI_init();
    SPI_Params_init(&spiParams);

    spiParams.frameFormat         = SPI_POL0_PHA0;
    spiParams.mode                = SPI_PERIPHERAL;
    //spiParams.transferCallbackFxn = transferCompleteFxn;
    spiParams.transferMode        = SPI_MODE_CALLBACK;
    spiParams.bitRate             = 4000000;

    spi_handle = SPI_open(CONFIG_SPI_CONTROLLER, &spiParams);
    /* Call driver init functions */
    GPIO_init();
    // I2C_init();
    // SPI_init();
    // Watchdog_init();
    SPI_transferCancel(spi_handle);
    SPI_close(spi_handle);
    /* Configure the LED pin */
    GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    GPIO_setConfig(CONFIG_GPIO_SPI_0_CSN, GPIO_CFG_IN_PU | GPIO_CFG_SHUTDOWN_WAKE_LOW);
    GPIO_setConfig(CONFIG_GPIO_0, GPIO_CFG_IN_PU | GPIO_CFG_SHUTDOWN_WAKE_LOW);
    GPIO_setConfig(CONFIG_GPIO_1, GPIO_CFG_IN_PU | GPIO_CFG_SHUTDOWN_WAKE_LOW);
    /* Turn on user LED */
    GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);

        sleep(time);
        GPIO_toggle(CONFIG_GPIO_LED_0);
        /* Go to shutdown */
        Power_shutdown(0, 0);
}

Thanks,
Alex F

Hi Alex,

With your code, I tried on custom PCB it didn't work. So I moved to development board (LP-EM-CC2340R5), it worked.

I repeated this exercise with my code. It worked on development board, but not my PCB.

I have noticed another issue with my board. After Power-on-reset the device fails to wake from buttons but wakes from chip-select only then device goes to shutdown. Subsequently, it is then able to wake up from buttons and chip-select line. TLDR; device is missing first wakeup from buttons otherwise it works as I expect strangely. I do not understand what's going on.

Can you suggest further action?

Regards,
Jaimin

Hello Jaimin,

If you have not already I would recommend getting your PCB reviewed by our team by submitting a request to the SIMPLELINK-2-4GHZ-DESIGN-REVIEWS Design tool | TI.com. As you have tried the code on both the PCB and Launchpad and seen different results this seems to stem from the PCB itself. 

Thanks,
Alex F

Hi Alex,

Thanks for your prompt response.

There's one difference with the test I did earlier. The SPI-CS line was left un-connected. However, on custom PCB this line is connected to the SPI Controller (master, RF432). On the SPI Controller side the chip-select line gets switched to GPIO output mode with High state and on CC2340 it is switched to GPIO input mode with internal pull-up for achieving least power consumption.

Regards,
Jaimin

Hello Jaimin,

I wanted to let you know of a recent test I did with the same code I provided earlier, in this test I grounded my SPI Chip Select pin which causes the device to always stay in shutdown even if I press button 1 or 2; note that as soon as I remove the ground from CS I can use button 1/2 to wakeup the device.

From what I can tell once the SPI CS pin is held active low to ground it will not wake up with the buttons. 

Thanks,
Alex F

Hello Alex,

I tried today and I see same observation as yours. I am expecting the device to still respond to wakeup if the device has gone to sleep.

My observation with logic analyzer indicates that grounding CS pin after device has gone to sleep wakes up the MCU and might be failing to enter shutdown. So I modified to code to turn-off led on PowerLPF3_ENTERING_SHUTDOWN event otherwise it remains on. I observed that the LED is turning off which means it is entering shutdown. Then, how does it fail to wake up?

Takeaway for me is that this is could be the root cause of my issue. So I will have to investigate the status of CS line to debug.
If not please clarify further.

Thanks,
Jaimin

Hello Jaimin,

Ajmeri Jaimin said:

My observation with logic analyzer indicates that grounding CS pin after device has gone to sleep wakes up the MCU

I also observed this, once grounding the pin it resets once but once it goes back to shutdown it never wakes up till you unground the pin, and once the CS pin is ungrounded the device wakes back up and can be controlled again by the buttons. 

I will need to investigate further on why the CS pin is causing this effect; as a test we could try disabling (or closing) the SPI to see if that can let us wake up while the CS pin is grounded (disableSPI function).

Thanks,
Alex F

Hi Alex,

We already have SPI_transferCancel(spi_handle) followed by SPI_close(spi_handle) function calls before entering shutdown in both your code and mine. Do you mean some other API? because I do not see disableSPI function in the driver.

Regards,
Jaimin

Hello Jaimin,

The "disableSPI" function is found in the SPILPF3DMA.c file; but SPI cancel and SPI close was what I was thinking of, so it's odd that we can't force a close here to return functionality to the buttons. 

/*
 *  ======== disableSPI ========
 *  Disables the SPI peripheral
 */
static inline void disableSPI(uint32_t baseAddr)
{
    HWREG(baseAddr + SPI_O_CTL1) &= ~SPI_CTL1_EN_EN;
}

Thanks,
Alex F

Hi Alex,

I probed the chip-select line today and took a quick capture with logic analyzer.

I see that the chip-select is held low after power-on-reset. 

Please find the link below for the capture file.
/cfs-file/__key/communityserver-discussions-components-files/538/cs_5F00_probed.zip

Regards,
Jaimin

Hello Jaimin,

In this case you do not have the chip select connected to ground correct? If not I will see if I can replicate this on my end. 

Thanks,
Alex F

Hi Alex,

The chip-select is not connected to ground.

Regards,
Jaimin

Hello Jaimin,

Is your chip select active low or active high here? In my simple test I do see the CS line go low after I disconnect power and then once I connect power it goes back to high, though normal reset did not do anything noticeable.

Is your specific concern about the area I cropped in the image? If possible can you share your protype code or setup here so I can test further? 

Thanks,
Alex F

Hi Alex,

The chip select pin is in active low configuration.

The cropped area of the image is my concern. You can see that button press detection is not waking up the device if the chip select is low, I am expecting it to wakeup. This is an issue that has to be investigated by TI from your earlier reply.

Why the chip select is low after reset?
The cropped area shows a case when both the MCUs are in IDLE state and go to low power mode due to inactivity. The other MCU, which is an SPI Controller (master), the chip select line is not hardware controlled by the SPI but is a GPIO controlled. So, after reset this MCU initializes SPI driver but the chip select remains low. Only during an SPI transfer the chip select line is controlled in Active Low manner. This MCU remains in IDLE state for some amount of time and enters low power mode if there's no activity, which explains the chip select low in your cropped area. If there's an acitivty it does an SPI transfer causing chip select to go momentarily go high, then low during the transfer and continues to reman high. Then enters low power mode again.

I hope this answers your question?

As workaround, during the initialization phase I made chip select high on the SPI Controller to see if cc2340 wakes up from buttons. It did wakeup, we already know the reason. I will have to test it thoroughly before accepting this as the solution.

Please note that the other MCU has NDA, I am willing to share the code directly with you or via business e2e support if that's possible.

Regards,
Jaimin

Hello Jaimin,

You could either share your code (or prototype SPI function) with me through the private message feature on E2E, or by reaching out to your assigned FAE who will make an email thread with me and you. 

Ajmeri Jaimin said:

MCU has NDA

This is a TI part? Or is this just in reference to the code being under NDA? 

Ajmeri Jaimin said:

As workaround, during the initialization phase I made chip select high on the SPI Controller to see if cc2340 wakes up from buttons. It did wakeup, we already know the reason. I will have to test it thoroughly before accepting this as the solution.

From our earlier observations this does seem like one of the paths we could take here. Forcing the CS high manually to allow us to have control. 

Thanks,
Alex F