ESP32-Based Environmental Monitoring PCB Randomly Resets When Sensor Module Is Connected

Hi everyone,

I’m working on a custom ESP32-based environmental monitoring project that collects temperature, humidity, and air quality data from multiple sensors. The prototype worked perfectly on a breadboard, but after moving everything to a custom PCB I’m running into some strange stability issues.

The ESP32 runs fine when powered alone, but as soon as I connect the sensor daughterboard through a board-to-board connector, I start getting occasional resets and sometimes corrupted sensor readings. The resets seem more frequent when Wi-Fi transmissions occur.

A few details:

  • 4-layer PCB with dedicated power and ground planes.

  • ESP32 powered from a 3.3V regulator fed by a 5V input.

  • Sensor board connected through a 10-pin connector carrying power, ground, I2C, and interrupt signals.

  • I2C traces are around 120 mm long due to the mechanical layout.

  • Decoupling capacitors are placed near the ESP32 and regulator, but not directly beside every sensor.

  • Ground return between the main board and sensor board currently uses only one ground pin in the connector.

I’ve checked the firmware and don’t see any obvious software issues, so I’m starting to suspect a PCB layout or signal integrity problem.

A few questions:

  1. Could the single ground connection between boards be causing ground bounce or return path issues?

  2. At what trace length should I start worrying about I2C signal integrity on a PCB?

  3. Would adding additional ground pins in the connector and placing local decoupling capacitors near each sensor likely improve stability?

  4. Are there any common PCB design mistakes when moving an ESP32 project from breadboard to production hardware that could cause intermittent resets like this?

I’d appreciate any suggestions on what measurements to take with an oscilloscope or logic analyzer before ordering another PCB revision.

Thanks!

Since the problem started after moving from breadboard to a custom board, I would first suspect layout and power distribution rather than firmware.

ESP32 can pull sharp current spikes during Wi-Fi transmission, so check the 3.3V rail on a scope while Wi-Fi is active. If you see dips or ringing, add more bulk capacitance near the ESP32 and review the regulator layout.

For the sensor board connection, I would also add more ground pins in the connector. One ground return for power, I2C, and interrupt signals is not ideal. A better pinout would be something like GND between sensitive signals, or at least multiple GND pins across the connector. You should read this guide on I2C designing considerations: Chip to Chip Communication Protocols: An Overview and Design Considerations - PCB Design Tutorial - PCBway

Also place small decoupling capacitors close to each sensor, not only near the regulator. On a breadboard, wiring sometimes hides these issues, but on a compact PCB the return paths and capacitor placement become much more important.

For I2C, 120 mm can work, but check SDA/SCL rise time on a scope and adjust pull-up values if needed.

Before ordering the next revision, I’d review the PCB layout carefully: regulator placement, ESP32 decoupling, connector ground pins, I2C routing, and return paths.

Thanks for the suggestions.

The next revision will probably use a cable assembly rather than a direct board-to-board connection because the sensor board location may change in future versions of the product.

That got me thinking about wiring harness design in general. Most of my previous projects have been fairly simple, so I’ve never paid much attention to the different wiring harness connector types available for embedded systems.

For applications like this—ESP32, low-voltage sensors, I2C, interrupt lines, and moderate vibration—are there particular wiring harness connector styles that are commonly preferred? I’m seeing everything from JST and Molex connectors to various locking and sealed connector systems, and I’m not really sure what factors should drive the selection.

How do you typically choose the connector type when designing a wiring harness for a sensor-based embedded product?

When selecting wiring harness connectors, I usually look at a few factors first: vibration, current requirements, serviceability, environmental exposure, and how often the assembly may need to be disconnected. Here are diff types of harness connectors: https://www.unikeyic.com/blog/wiring-harness-connector-types.html which one you are selecting for your application?

For sensor-based embedded systems, I’ve seen JST, Molex, and various locking connector systems used successfully. The “best” choice often depends more on the application than the connector brand itself.

Thanks, that overview was actually helpful. I wasn’t aware there were so many different wiring harness connector categories aimed at different environments.

Based on the descriptions, I’m probably leaning toward a locking connector rather than a simple friction-fit style since the units may be installed in areas with some vibration and occasional maintenance.

The sensor board only carries 3.3V power, I2C signals, and a couple of interrupt lines, so the current requirements are fairly low. My main concern is long-term reliability and avoiding intermittent connection issues that could be difficult to diagnose in the field.

For those who have deployed similar sensor systems, have you found that locking connectors are generally worth the additional cost, or have standard JST-style connectors been sufficient in practice?

For low-current sensor applications, JST connectors are usually sufficient if the enclosure stays closed and the environment is fairly clean.

However, since you’re carrying I2C and interrupt signals between boards, I’d personally add a couple of extra ground pins and use a connector with some form of locking or retention. The added cost is small compared to troubleshooting intermittent issues in the field.

Before ordering a new PCB revision, I’d also recommend checking the 3.3V rail and I2C signals with a scope during Wi-Fi activity. That should help narrow down whether the problem is power-related or connector/layout-related.

Please post an update once you’ve had a chance to scope the supply rail and signals, I’d be interested to hear what you find.