My application acts as wifi module to another host processor which also control power of the wifi module. After powering up, the is some communication between the to over UART1, mostly initiated by the esp32. This also works so far. But after a short while, there's a strange behavior of the TX line of the esp32. It seems to be related to light sleep mode and probably also system load. The application itself looks for an access point to connect to and tries to establish a tcp connection to a remote server. Most of the time the unnormal activity on the TX line happens in between IP_EVENT_STA_GOT_IP and the tls connection which gets opened as soon as the ip is assigned.
The activity on the TX line is not initiated by the application and after each rising edge of the TX line and RX-TOUT interrupt is generated with one byte in the rx fifo. See screenshot.
similar but wifi association is faster, therefor it happens earlier, still no TX software activity around the time of the strange falling edge of the TX line
After about 300ms of strange behavior, the TX line continues to operate normally, RX as well.
If I disable the light sleep mode until the tls connection is up, then I cannot reproduce the issue.
it seems this was cause by CONFIG_GPIO_ESP32_SUPPORT_SWITCH_SLP_PULL=y without configuring the tx pin to be pulled up during sleep. so I'll close it...
Environment
Problem Description
My application acts as wifi module to another host processor which also control power of the wifi module. After powering up, the is some communication between the to over UART1, mostly initiated by the esp32. This also works so far. But after a short while, there's a strange behavior of the TX line of the esp32. It seems to be related to light sleep mode and probably also system load. The application itself looks for an access point to connect to and tries to establish a tcp connection to a remote server. Most of the time the unnormal activity on the TX line happens in between
IP_EVENT_STA_GOT_IP
and the tls connection which gets opened as soon as the ip is assigned. The activity on the TX line is not initiated by the application and after each rising edge of the TX line and RX-TOUT interrupt is generated with one byte in the rx fifo. See screenshot.similar but wifi association is faster, therefor it happens earlier, still no TX software activity around the time of the strange falling edge of the TX line
After about 300ms of strange behavior, the TX line continues to operate normally, RX as well. If I disable the light sleep mode until the tls connection is up, then I cannot reproduce the issue.