djangoa
commented
6 months ago Further to my initial comments, I've caught the select() timeout issue, with more debugging enabled (CONFIG_LWIP_DEBUG, CONFIG_LWIP_ETHARP_DEBUG, CONFIG_LWIP_SOCKETS_DEBUG, CONFIG_LWIP_IP_DEBUG, CONFIG_LWIP_TCP_DEBUG), both during and after connecting to a MQTT broker:
timeout-pre-conn_debug.log timeout-post-conn_debug.log timeout_tcp_debug.log
In the last log, additionally TCP_INPUT_DEBUG, TCP_OUPUT_DEBUG is enabled and around Line 430 the device has a timeout. It looks like it's receiving broadcasts from another IP but not from the broker. So maybe if I'm interpreting the log correctly the TWT teardown is a red herring unless directly after the setting up TWT. I think I'm also suffering from https://github.com/espressif/esp-idf/issues/6607#issuecomment-799239990 where LWIP_TCP_TMR_INTERVAL, LWIP_TCP_RTO_TIME are set too high by default (750ms) for the first SYN-SENT to be retransmitted before my application invokes it's own mqtt_client event timeout. It would be good to know if there is any expectation of having a delay between tearing down a TWT and the wifi fabric becoming usable for connections?
Regarding the power issue I've adapted https://github.com/espressif/esp-idf/issues/4628#issuecomment-575535394 to suspend the lwip tcpip task before auto light sleep and wake it after. This has resolved the current spikes due to tcp_slowtmr and etharp_timer but I would have thought that auto light sleep should do this automatically unless there's some technical reason this shouldn't be done? I'm getting around 50uA, at the board level, in light sleep now:
I'm still experiencing issues though with auto light sleep being unreliable (with & without the suspending the lwip tcpip task) and sometimes consuming 16mA and other times 38mA:
xuxiao111
Answers checklist.
IDF version.
5.1.3
Espressif SoC revision.
ESP32-C6-FH4
Operating System used.
Windows
How did you build your project?
Eclipse IDE
If you are using Windows, please specify command line type.
None
Development Kit.
DFROBOT FireBeetle 2 ESP32 C6 IoT Development Board
Power Supply used.
USB
What is the expected behavior?
Calling _esp_wifi_sta_itwt_teardown(flowid) tears down the selected Targeted Wake Time and allows network traffic to flow freely through the wifi interface on receiving a WIFI_EVENT_ITWT_TEARDOWN event.
What is the actual behavior?
Calling _esp_wifi_sta_itwt_teardown(flowid) intermittently causes select() timeouts when creating new connections.
See the attached DEBUG Logs of an application I've been working on that integrates the itwt and mqtt tcp examples and sits in a loop publishing data from a sensor to a MQTT broker then sleeping for 5minutes.
In the Debug Logs:
Steps to reproduce.
Setup and start wifi. Create a non trivial TWT agreement with an AP using a service period of around 5mins (e.g. 46875 << 13) , then in a loop:
Debug Logs.
More Information.
I've tried many things to work round the issue including turning off various power saving techniques to omit them as a possible cause:
I've also tried idling after a teardown with vTaskDelay() before creating a connecting. Finally, I've tried using _esp_wifi_sta_itwt_teardown(FLOW_IDALL) to no effect. It also doesn't matter what timeout I give (100ms or 10000ms) when creating a tcp mqtt connection, it still fails taking the full timeout duration.
For context the wifi connection seems OK and is to a Ubiquiti UniFi U6 Enterprise AP with ~-40dbm RSSI and ~20% TX retries. Finally and anecdotally, the errors "seem" to come in waves as if related to interference? I've attached my sdkconfig.zip from the application I'm experiencing the issue in case I've missed anything.
On a related note, I'm also experiencing strange behaviour and fairly high power consumption in auto light sleep during TWT, ~110ua vs ~35ua as advertised, with a period of 1s:
These don't seem to be ARP related as per: https://github.com/espressif/esp-idf/issues/12441#issuecomment-1775029218. Setting ARP_TMR_INTERVAL to any other value, currently set at 2000ms in the graph, does not change the interval shown on the graph. I've also seen strange transitions to auto light sleep after setting up a TWT that looks similar to https://github.com/espressif/esp-idf/issues/11858#issuecomment-1640244734 where the MODEM power domain is not powering down and thus current draw is around ~300ua. This can be seen earlier in the same current trace as above in the previous iteration:
Furthermore, I've tried switching dev boards vendors (both exhibit the same power draw), disconnected all peripherals and disabled/floated/hold all relevant GPIO to no avail. I've also edited sleep_modem.c with _esp_sleep_cpu_retentioninit() and get the same power draw without initialising wifi and manually invoking light sleep but strangely without the 1 second pulse in current consumption.
Hopefully someone can point me in the right direction, if I haven't provide enough detail.