LAUNCHXL-CC3235SF: Can the device be woken up with HTTP GET and POST requests when it is in sleep mode?

Hi,

Basically this feature is already implemented, meaning that if you are connected to the AP and most of the time in LPDS, the device would only wakeup for beacon reception which is mandatory. If a packet is sent to the device (regardless what packet), it would wakeup on the next beacon and read the TIM IS from the beacon and understand it has a packet pending and then would poll it from the AP and go back to LPDS.

There is a mechanism called RX filters (see chapter 11 on the NWP guide) that allows setting some patterns and rules to further "play" with what wakes up the device but it is more complicated to implement and I am not sure you need it.

Regards,

Shlomi

Hi

I put the device in LPDS mmod. It draws low current in this mode. I want to wake it up with HTTP GET in this mode.

Let me tell you my main purpose, you give me the most correct method. I will send data to the device by sending http get requests 4-5 times a day. I want the device to sleep the rest of the time. In this way, I aim to increase the battery life to 6-7 months. For this, I want to put it to sleep in LPDS mode and wake it up with HTTP queries, but I couldn't understand if this is possible. I can do the same thing with the GPIO interrupt, but I can't implement it because I need a wireless solution.

What I suggest is that you read through the following overview https://www.ti.com/lit/an/swra594a/swra594a.pdf

In high level, there are two modes, intermittently connected and always connected.

Staying in LPDS correlates to always connected mode where most of the time the device is in LPDS while the device wakes up for beacon reception (you can even lower the average current by waking up every few DTIMs - see LSI mode in this document).

The main advantage here is the fact that you are always connected to the AP, meaning the latency is very low when trying to communicate via the cloud and you don't need to do much to wakeup the device, just send data to it and it will automatically wakeup and fetch the data which is signaled by the AP on beacons.

Shlomi

Hi

If I set the method you mentioned to wake up once every half hour, exchange data and wake up, will the average current value fall below 5mA?

once every half an hour is a long time, you can go to complete shutdown. But in complete shutdown you would need to power on the device (on a timer maybe).

If you want to avoid it and remain connected to the AP, even if you wakeup every beacon (102.4mSec), you still draw on the average less than 1mSec so you should be fine.

There are still other factors to take into consideration like keepalive packets on Wi-Fi, TCP keepalive, DHCP renew, Wi-Fi broadcast key exchange, and more.

Having said that, the gap between 1mSec and 5mSec on the average is large so I believe you have enough margin to remain in always connected mode.

Hello;
I don't know what you mean by 5mSec. I'm talking about the current drawn by the device. So when I use the method you mentioned, will the current drawn by the device be below 5mA? I actually wanted to ask.

Thank you.

sorry, typo. I meant 1mA and 5mA above.

See the table for the average current in the doc I shared.

Even the default wakeup time every beacon gives a number below 1mA.

Hello;
First of all, thank you for your quick response.

I want to make sure I understand you correctly. I can put the device to sleep using the LSI method. And I can wake it up with an http get request, this is possible, right?

According to what you said, I created a structure like the one below.
void configureDTIMAndListenInterval(void) {
uint16_t listenInterval = 5; // Adjust to desired beacon interval (e.g., 5 beacons)
int32_t status;

// Configure Listen Interval
status = sl_WlanPolicySet(SL_WLAN_POLICY_PM, SL_WLAN_LOW_POWER_POLICY, (uint8_t *)&listenInterval, sizeof(listenInterval));
if (status < 0) {
Display_printf(display, 0, 0, "Failed to set Listen Interval: %d", status);
} else {
Display_printf(display, 0, 0, "Listen Interval set successfully: %d", listenInterval);
}
}

Thanks.

your basic understanding is correct but this is not the API.

Look at the wlan.h header file for an example.

The option is SL_WLAN_LONG_SLEEP_INTERVAL_POLICY and not SL_WLAN_LOW_POWER_POLICY, and the interval is given in mSec.

Hello;
void configureDTIMAndListenInterval(void) {
uint16_t listenInterval = 5; //
int32_t status;

// Set DTIM and Listen Interval settings
status = sl_WlanPolicySet(SL_WLAN_POLICY_PM, SL_WLAN_LONG_SLEEP_INTERVAL_POLICY, (uint8_t *)&listenInterval, sizeof(listenInterval));
if (status < 0) {
Display_printf(display, 0, 0, "Listen Interval set failed: %d", status);
} else {
Display_printf(display, 0, 0, "Listen Interval set successfully: %d", listenInterval);
}
} When I set it like this, I get the Listen Interval failed to set error.

Thanks.

you are not following the attached example.

please follow exactly the types and see how it is set.

void configureDTIMAndListenInterval(void) {
int32_t status;
SlWlanPmPolicyParams_t PmPolicyParams ;
memset(&PmPolicyParams,0,sizeof(SlWlanPmPolicyParams_t));
PmPolicyParams.MaxSleepTimeMs=100;
// DTIM ve Listen Interval ayarlarını yap
status = sl_WlanPolicySet(SL_WLAN_POLICY_PM, SL_WLAN_LONG_SLEEP_INTERVAL_POLICY, (uint8_t *)&PmPolicyParams, sizeof(PmPolicyParams));
if (status < 0) {
Display_printf(display, 0, 0, "Listen Interval ayarlanamadı: %d", status);
} else {
Display_printf(display, 0, 0, "Listen Interval başarıyla ayarlandı: %d", PmPolicyParams.MaxSleepTimeMs);
}
} 

I set it this way, but the device does not go to sleep mode. There is a current value of 30mA as normal. If you want, I can share the other parts of the code, but it is certain that the device does not go to sleep.

setting looks OK but I would choose a larger number than 100mSec.

Try to set it to 400mSec so we are sure that it is not waking every beacon.

And at least from the 30mA you mentioned, it looks like the current draw is coming from the ARM M4 (application processor) that is not going into LPDS and not the MAC/PHY.

Thank you for your answer. The process was completed successfully. When you compile the code in CCS studio, a hex code appears in the files. How can we load this hex code into the processor? Is there any document related to this subject?

when you compile with ccs, you should have .out and .bin. Where do you see .hex?

Actually my problem is this. I need to send the current version of the software to my remote customer but I can't send the source code. If I'm not mistaken, the .sli extension file is extracted specifically for the device. That's why I'm looking for a solution.

where do you see an hex file? you should see the .out and .bin under 'MCU+Image' directory of your workspace.

then you should add the bin file as the mcu image into Uniflash and you can get the image.

you can always take the .bin and use standalone Uniflash to create all types of images.

I cannot install a program with a file other than the .sli extension

again, you can fetch the .sli with Uniflash instead of CCS. If you insist on CCS, I believe you can change the 'Image Mode' on syscfg from Development to Production and recompile so the image can fit all devices.