ESP32 Pico D4 - WiFi on/off causes effects on the PCB

[_Kermit_]

Hi,

I am working on an ESP32 based board and running into some issues. I am using the ESP32-Pico-D4 with a custom made PCB. On a first glance, anything works fine with my board. I can program the ESP32, TFT and buttons are working, battery is charging and so on.

There is, however, some voodoo going on. I suspect there are some HF issues with my board but I have limited knowledge on how to look into it. Here are two "anomalies" with my board I have experienced so far. But first some more background information. As you can see in the attached schematics I have a LiPo charging circuit (based on MCP73831) on the board as well. The charger chip has a status pin which signals wether the attached battery I charging or not. Charging the battery, the LED is on (as expected). In case no battery is attached or the attached battery is full, however, the LED is flickering instead of being off as supposed to.

Here comes the kicker, though. In case I turn the ESP32's WiFi off, the flickering of the LED stops immediately (WiFi is toggled via software during runtime). Turning WiFi back on results in the flickering LED again.

The second issue is associated to WiFi as well. The PCB has an TFT display as well as push buttons in order to navigate a menu structure. When WiFi is on, the buttons (pull down) work reliably. Once WiFi is turned off, however, pressing my "down" button triggers my "down" AND "left" button. Although they are connected to different GPIOs. Turning WiFi back on - the buttons are working normal again.

As I mentioned in the beginning, I suspect to have some HF issues (that is just my guess, however). My amateur view on that is that there seems to be something going on on my GND and Vcc lines - hence the flickering of the LED or the misfiering of the push buttons.

I tried to follow the ESP32 hardware implementation guide (is there a dedicated one for the Pico D4?) and also consulted the Datasheet of the MCP73831 (LiPo charger). Form my point of view, I connected anything correctly - but apparently that is not the case.

Do you have some ideas how I can figure out what is going on?

NOTE: Attached is the full schematic. The LED_EN1 bridge is closed on my PCB.

[ESP_Sprite]

Charging the battery, the LED is on (as expected). In case no battery is attached or the attached battery is full, however, the LED is flickering instead of being off as supposed to.

Here comes the kicker, though. In case I turn the ESP32's WiFi off, the flickering of the LED stops immediately (WiFi is toggled via software during runtime). Turning WiFi back on results in the flickering LED again.

What you're likely seeing is flickering because the charging chip is trying to charge anything connected to the battery node (in this case: C14) to 4.2V. C14 charges rather quickly, so the light turns on for a short while before turning off again. As C14 discharges by itself and through the rest of your circuit, it quickly dips below 4.2V again, repeating the cycle. My guess is that when WiFi is on, the ESP32 pulls a lot more power and the circuit around Q1/D3 somehow manages to pull that from the battery node as well. That makes the voltage over C14 never reach 4.2, and the LED never goes off. (I assume that is what you're seeing.)

The second issue is associated to WiFi as well. The PCB has an TFT display as well as push buttons in order to navigate a menu structure. When WiFi is on, the buttons (pull down) work reliably. Once WiFi is turned off, however, pressing my "down" button triggers my "down" AND "left" button. Although they are connected to different GPIOs. Turning WiFi back on - the buttons are working normal again.

That, I cannot explain.

[_Kermit_]

Thanks for you replay, ESP_Sprite! Really appreciate it. I will look into it what could cause C14 to rapidly discharge. Interestingly, whenever WiFI is off (i.e., the ESP32 draws less power) I do not see that behaviour (flickering / C14 discharging).

As for the button press issue: Of course, a remote diagnosis of such an issue is nearly impossible. But do you have some ideas/tips/hunch how I could start to figure it out? What are common steps to undergo?

[ESP_Sprite]

As for the button press issue: Of course, a remote diagnosis of such an issue is nearly impossible. But do you have some ideas/tips/hunch how I could start to figure it out? What are common steps to undergo?

How many boards do you have? If it's only one, it may be a fluke (bad soldering, very conductive flux residue, badly soldered pulldown resistor, ...), if you have multiple that do this, it's likely a design thing.

[_Kermit_]

How many boards do you have? If it's only one, it may be a fluke (bad soldering, very conductive flux residue, badly soldered pulldown resistor, ...), if you have multiple that do this, it's likely a design thing.

That's part of my problem. The issue is on all of my five boards.

However, I figured out and fixed the issue with the buttons behaving oddly when WiFi is turned off. As you can see from the schematic, the buttons have a Pull-Down logic. The issue was that the resistors for the "Down" and "Left" button were connected to a ground plane (i.e., copper fill) that was not connected to the rest of the PCB's ground plane (as well as GND from the USB power source). This means instead of a Pull-Down setup, the other end of the button's resistors were floating.

This floating results in multiple button presses detected / interpreted by the ESP when WiFi is off. When WiFi is on, however, the buttons worked. My explanation for this is as follows: The PCB antenna as well as the C-C-L network connecting it to the ESP sits also on the floating GND plane. My guess here is that whenever WiFi is enabled, the floating gets stabilised/grounded by the antenna. Once WiFi is turned off, it is back to floating again.


This leaves me with the flickering charging LED. But that might not be related to the ESP at all - as you already suggested in your second post.

[ESP_Sprite]

Hah, disconnected ground plane, that'll do it. For what it's worth, most PCB programs have a 'design rule check' feature that can find unconnected nets; that may have found this issue for you. Interesting that it's connected to the WiFi behaviour, though; I wouldn't expect that.