• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 40 subscribers
  • Views 204 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220MODA: How to optimize the power consumption in CC3220MODASF12MONR

Murali C
Prodigy 160 points
Part Number: CC3220MODA
Other Parts Discussed in Thread: CC3220S, CC3220R, CC3220SF, CC3120

Hi,

We are using CC3220MODASF12MONR module as main controller. We are looking for optimum usage of power modes in our application. So far we are using the always connected scenario where the NWP is in Long Sleep Interval (LSI) mode. The max sleep parameter is set to 100 ms. The average current consumption in this mode is 27 mA.

Our application demands the current consumption to be in the order of uA. So as per the SWAS05B CC3220R, CC3220S, CC3220SF document, both the MCU and the NWP are to be in LPDS. We have the following questions:

  1.  Will the MCU be able to perform other activities like data acquisition through ADC/SPI in LPDS mode? As per the SWRA502C CC3120, CC3220 SimpleLinkTm Wi-Fi® Internet-on-a chipTm Networking Subsystem Power Management document, when the MCU is in LPDS mode all other logic except the hibernate

logic and top level logic are power gated. So does this mean other logic will not work?

 

  1. The Power Measurement example in the SDK puts the whole device to LPDS. Is there a possibility of sending just the MCU or NWP to LPDS. If so, how can it be achieved?

 

  1. We need the NWP to send data once every 100 ms and then sleep for rest of the time. Will it save power, if it remains connected to AP or should we sl_Start and sl_Stop everytime so that it reconnects to the AP and sends data through TCP sockets?

 

  1. The Power Management document says that the sl_WlanPolicySet configures the device management policy. So it means that it works on both MCU and NWP . Is that right?

 

  1. We are trying to configure the MCU LPDS, NWP Idle connected. In which configuration mode can be a power reduction solution? 

 

 

Please guide us.

Looking forward your response!

Thanks,

Murali C

  • 0
    TI__Mastermind 40965 points

    Hi Murali,

    To answer your questions:

    1. No, in LPDS the ADC, SPI, and other peripherals are unable to be used. Your application will need to exit out of LPDS first in order for those peripherals to be enabled.

    2. Yes, the MCU and NWP can enter different power states independently. For example, you can put the NWP into hibernate by using the sl_Stop() function to halt its activity and effectively Wi-Fi functionality. Likewise, the NWP can be in LPDS while the MCU is active. In fact, by default the NWP will try to enter LPDS as much as possible automatically. You have to manually set the NWP into always on mode using the sl_WlanPolicySet API in order to disable the use of NWP LPDS.

    Now, given that the NWP will always intelligently use LPDS as it deems optimal, the main policy to change is whether LSI and IoT low power mode are used. The options to set those are demonstrated in the power_measurement example, and with your power requirements, using higher LSI settings such as in the 400ms range might produce better results.

    3. If you need to send data once every 100ms, then it is not worth it to perform an sl_Stop()/sl_Start() cycle. As you point out, you will need to reconnect to the AP, reacquire an IP with DHCP, and then reopen your sockets and perform TLS handshakes if needed. The typical break-even point for where setting a device in hibernate and disconnecting Wi-Fi saves power over simply staying connecting in LPDS is around 30 seconds to a few minutes, depending on the DHCP/TLS overhead in your use case and network environment.

    4. No, the sl_WlanPolicySet() API only works for the NWP. For the MCU, your application needs to actually handle the LPDS transitions itself. This LPDS handling is provided in the SDK, and actually is a part of the driver and RTOS layers. You'll notice in the power_measurement example that there is the Power_enablePolicy() API that enables and disables LPDS. There is a lot of code in the RTOS that allows a seamless switch in and out of LPDS, but for the purposes of your application code all you need is use Power_enablePolicy() to enable LPDS.

    5. Using the Always Connected usecase of the power_measurement example should allow you to use the correct power settings for MCU LPDS, NWP Idle connected. Are you using that power mode and seeing your 20mA average current?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 160 points

    Hi Michael,

    Thanks for the detailed explanation.

    2. Yes, the MCU and NWP can enter different power states independently. For example, you can put the NWP into hibernate by using the sl_Stop() function to halt its activity and effectively Wi-Fi functionality. Likewise, the NWP can be in LPDS while the MCU is active. In fact, by default the NWP will try to enter LPDS as much as possible automatically. You have to manually set the NWP into always on mode using the sl_WlanPolicySet API in order to disable the use of NWP LPDS.

    What will be the current consumption when MCU is active, NWP is in LPDS mode? How can it be done ?

    5. Using the Always Connected usecase of the power_measurement example should allow you to use the correct power settings for MCU LPDS, NWP Idle connected. Are you using that power mode and seeing your 20mA average current?

    We are measuring average current of 6 mA in MCU LPDS, NWP idle connect mode. We are transmitting data 5secs once  with using always connected usecase.

  • 0 in reply to Murali C
    TI__Mastermind 40965 points

    Hi,

    The current consumption of the MCU active, NWP LPDS case is best reflected by the MCU active, NWP idle connected case in the datasheet power consumption specs. This is since using the default NWP power settings, the NWP will try to be in LPDS as much as possible, and this applies while the CC3220 is still connected to a WI-Fi AP, in effect while in idle connected mode.

    In order to check that case, the simplest method would be to run the Always Connected test case of the power measurement example, but with one small modification - comment out the Power_enablePolicy() call in the UseCase_AlwaysConnected case in mainThread(). That will disable LPDS.

    If you do not comment that line out, the CC3220 MCU should be able to enter LPDS. So the expected current is supposed to be <1mA. Do you have a CC3220 launchpad on hand that you can test with? I'm wondering if you are able to reproduce your test on a launchpad EVM, and see if you get the expected power numbers. This will narrow down the issue, and allow us to see if it is a testing issue or a potential board issue.

    Regards,

    Michael