Open tohyf opened 4 years ago
tohyf
commented
4 years ago I found out that the 13.56MHz RFID module(MFRC522) that is also present on the same board, is interfering the ESP32. Once I turn off the RFID module the ESP32 WiFi works fine. The question is, why is the wifi (working at 2.4GHz or 2400MHz), is susceptible to 13.56MHz interference? Is the RF circuits not filtering the input correctly? Updated the title to reflect the actual issue.
Alvin1Zhang
commented
4 years ago Thanks for reporting and sorry for late reply. Is it convenient for you to share PCB layout of the hardware, this would help us in further debugging. If it is not convenient, would you please help write mail to sales@espressif.com? Thanks.
tohyf
commented
4 years ago Ok, will take a photo later
tohyf
commented
4 years ago The ESP-WROOM-32D is mounted upside down on a small board on the left, plugged onto the PCB via 0.1" header. There is a 10uF decoupling cap on the bottom PCB very close to the ESP header. The RFID module is plugged on the right, also via a 0.1" header. As you can see the RFID loop antenna is away from the ESP32.
jack0c
commented
1 year ago I not sure if it is too late, judging from the actual picture, it may not be interference between antennas, or it may be that the layout of the board is not good enough to cause signals to affect each other on the floor, or it may be brought out by GPIO. It is estimated that the conclusion can be reached only after measured done on the board.
tohyf
commented
1 year ago The board on the bottom has full ground plane at bottom layer. Shielding is good. The only connection to the ESP32 is UART TX and RX , plus the power and gnd (4 pins). The UART signals looks quite clean.
djixon
commented
8 months ago In such a tight design, without any intermediate shielding in between RF TAG module and ESP I would consider temporar 3.3V power supply for RF TAG module under full control of ESP. For example, take a single MOSFET (as switching element) and provide 3.3V power supply for RF TAG module through it, while its gate is under the control of ESP by any availab;le output free pin. If you are using N-Channel mosfet, then connect its gate with some 10K pulldown resistor to the ground so you are absolutelly sure that during power up cycle RF TAG module is without any voltage supply so it will stay turned off. Once the ESP is booted properly, you can power up RF TAG module at any time it is needed, by setting high logic level on that output pin controling the gate of the mosfet. Also if RF TAG module is not required at some running phases, you can always turn it off by low logic level on that pin. Such setup could possibly allow you to catch what exactly produce that issue with powering up the RF TAG module. Also make sure that you skip SPI setup for RF TAG module during powering up cycle. Just call that routine once you powered up RF TAG module. Also you can deinitialize SPI to free up resources just before you decide to shut down the module by pulling down that pin. Good luck.
Environment
git describe --tagsto find it): v4.0-174-gf9cb434eextensa-esp32-elf-gcc --versionto find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0Problem Description
When the ESP32 is power cycled (power completely turned off and turn on again), sometimes it will boot into a "bad state" and WiFi will connect slower than usual and TCP connections (I am using ESP-TLS) will be connecting very slowly and respond slowly. If I power-cycle it again, it will fix the issue. Update: found out that turning off the 13.56MHz RFID scanner module solves the issue.
//Detailed problem description goes here.
I am developing a hardware that will need to be power-cycled very often, and the ESP32 is used as a standalone wifi module with AT command firmware (I originally use the official esp-at but their support is too slow so that I write myself from scratch to try fix the issue). A UART port is used to talk with ESP32. I originally thought there was some firmware issue in ESP-AT that doesn't init the ESP32 correctly leading to the issue. It seems like it is still present (but happens less often) in my own version of ESP-AT firmware. The code that I test is very simple. After it boot up, an external microcontroller will wait ESP32 to be ready before telling it to connect to a WiFi AP. After WiFi got IP, then it will open a TCP port to a server and send some HTTP request to it, and then receive the HTTP response before server closes the port.
Expected Behavior
The ESP32 should behave the same way on every boot up, which quickly connect to WiFi, quickly connect to server via TCP and get response from it. The time taken for the TCP connection (from open to close) is usually less than 1.0 second.
Actual Behavior
About 10% of the time, it will boot into a bad state and all the WiFi and TCP (ESP-TLS) APIs work very slowly, and sometimes will timeout or error. When this happen, the total time taken for the TCP connection goes up to 10 seconds.
When it boot up in a "bad state", this is what happens: esp_tls_conn_new() opens a non-SSL port very slowly (a few seconds) esp_tls_conn_write() works very slowly. esp_tls_conn_read() returns the data slowly from server, and sometimes delay very long before return -1 when port closed by server (usually it immediately returns 0 when port is closed by server).
Steps to reproduce
Code to reproduce this issue
// If your code is longer than 30 lines, GIST is preferred.
Debug Logs
I have tried to debug it using Wireshark. Filtered with only TCP or HTTP. 192.168.0.184 is the ESP32 device. When it is booted into "good state" all packets are sent quickly without retransmissions.
When it is booted into "bad state", I see a lot of TCP packet retransmissions.
sdkconfig.zip
Other items if possible
buildfolder (note this may contain all the code details and symbols of your project.)