CC3220MODA: Using TIDC-01005 reference has high Wi-Fi power consumption.

Aichi Chen

Part Number: CC3220MODA
Other Parts Discussed in Thread: TIDC-01005, CC2640

Hi,

When we are using tidc-01005 with CC3220/CC2640, and following the guide to build it up then encounter high power issue around 7-8mA.

Originally we though this may BT issue so post here: (You will know more details about this issue)

https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/bluetooth-forum/992562/cc2640r2f-high-power-consumption-when-cc2640-advertise-for-each-500ms/3668933#3668933

But know, we found that once CC3220 run SAP_OPEN(), it will let CC3220 waste a lot of power...we have no idea how...and confirm UART pins does't have power leakage...

The customer is using CC3220 TI module and CC2640 launchpad, but still has this issue.

Hopefully we have fix this soon as this block customer MP date.

Schedmatic is here:

over 3 years ago

0 Vincent Rodriguez over 3 years ago

TI__Mastermind 28285 points

Hi Aichi,

This is likely a software issue causing the device to stay in higher power modes. I will reach out and get someone from our SW apps team to support.

BR,

Vince

0 Sarah P over 3 years ago in reply to Vincent Rodriguez

TI__Mastermind 38980 points

Hi Aichi,

When you call SAP_OPEN(), the CC3220 application MCU is opening a UART peripheral with RX enabled. As long as this is open, the CC3220 application MCU cannot go into a low-power mode. I would expect the current consumption to be higher during this period. In the demo, we expect the provisioning process to open the peripheral, exchange AP credentials, and then close so the CC3220 can go back into a low-power mode.

Are you leaving the peripheral open for a long period of time? In a real-world application, I would suggest implementing some timeout to close the peripheral if it is waiting too long for provisioning.

Best regards,

Sarah

0 Aichi Chen over 3 years ago in reply to Sarah P

Expert 1550 points

Hi Sarah,

The reason we keep this SAP_OPEN() not like tidc-01005 just we would like to keep Bluetooth advertising and connectable for some reason. And we know now if we do SAP_CLOSE, the power consumption is fine and BLE is able to keep advertising not for provisioning.

For this issue, we have 3 ideas:

1. Set NPI_FLOW_CONTROL=1 in ~\simplelink_sdk_ble_plugin_3_20_00_24\source\ti\npi\

Could you let me know whether it enable power saving by NPI_FLOW_CONTROL define?…

If yes, how to build it?

2. Regarding to SAP/SNP, if we can disabled SRDY and use gpio_setConfig to re-config MRDY as interrupt pin in CC3220, and if CC2640 want to send data, just assert and open UART to access it, after finish it, just close UART in CC3220 and de-assert.

3. Similar to 2, just use another wake-up gpio as interrupt in cc3220, once assert, just SAP_OPEN then exchange data and SAP_CLOSE after transmit complete.

Could you please share suggestion about above? Or do you have better suggestion?

+1 Sarah P over 3 years ago in reply to Aichi Chen

TI__Mastermind 38980 points

Hi Aichi,

Enabling flow control on the CC2640 unfortunately will not change the way the CC3220 power policy handles the UART peripheral. Your suggestions 2 and 3 would work.

You can also try using the UART_CMD_RXDISABLE/UART_CMD_RXENABLE configuration. The UART peripheral only keeps the application MCU awake if it is pending on an RX interrupt. It can be open for write-only and still go into LPDS. For example, we use the following code when we open a UART peripheral to print logs to a serial terminal:

/* Remove uart receive from LPDS dependency */
UART_control(uartHandle, UART_CMD_RXDISABLE, NULL);

Instead of reopening and closing the UART peripheral on an interrupt pin, you can enable or disable the RX for when you expect data.

Best regards,

Sarah

Wi-Fi

Wi-Fi forum

CC3220MODA: Using TIDC-01005 reference has high Wi-Fi power consumption.