STM32-Based Data Logger Experiencing Occasional Communication Errors After PCB Assembly

[MariaWilliams]

Hi everyone,

I'm developing a small STM32-based data logger that collects sensor readings and periodically sends the data to a host system over UART.

The firmware appears stable, but after moving from a development board to a custom PCB I'm occasionally seeing corrupted packets and missed responses. The issue is fairly rare, which makes it difficult to troubleshoot.

The design includes:

• STM32 MCU
• Multiple analog sensors
• UART communication
• External 12V power input
• Custom PCB

A few questions:

• Have you encountered similar communication issues after moving from a dev board to a custom PCB?
• What PCB layout mistakes most commonly affect UART reliability?
• Are there recommended grounding or decoupling practices around the MCU and communication circuitry?
• Would you recommend keeping sensor, power, and communication connectors physically separated on the board?

The PCB will likely be manufactured through PCBWay, and I'm also evaluating Molex connectors for the external wiring, so I'd appreciate any recommendations before ordering the next revision.

Thanks!

 

[Harald Kapp]

A well designed PCB is usually superior to a breadboard. If it is not, it is not well designed. Some possible issues:

• insufficient decoupling capacitor. Typically 100 nF per chip placed directly next to the power supply pins are used. In difficult cases capacitors of different capacitance are used to flatten the frequency response.
• insufficient power supply and grounding. Use a ground plane if possible, avoid breaking the ground plane by e.g. traces for signals.
• unclever routing. Keep traces as short as possible. Avoid long parallel traces. Keep sensitive traces (inputs) away from high speed signals (e.g.clocks).
• functionally different circuit parts not well separated. A well known example are analog and digital circuit parts which should be kept separate to avoid distortion of the analog signal by digital signals.

You can find these and many other general recommendations on the internet using serach terms such as "pcb design rules".

If you want to get more detailed help, show us your circuit diagram and PCB layout. Also desrcibe in more detail what you mean by

corrupted packets and missed responses.

Do you have access to an oscilloscope for tracing the affected signals? Seeing the actual distortion may offer additional hints at the source of the issue.

Cheers

Harald

 

[danadak]

If you have a DSO place it on infinite persistence, say 100 mV / box, 10 mS to start,
edge triggered around 50 mV, AC coupled, and look at power rails for pk-pk noise.

Type of bypass caps for bulk matter :

OSCON is polymer tant

---

Use a bulk and a ceramic disk (.1 uF) in parallel.

Is processor rebooting or just a a particular measurement bad, a particular sensor, etc..
For sensors you can set up dso to trigger on invalid logic levels or timing as well in case a
sensors COM interface is suspect.

Sensors mostly I2C or SPI or UART or One Wire or Analog or .... at interface ?

 

[bidrohini]

I've run into similar issues before, and in my case, the problem ended up being related to grounding and connector routing rather than the UART peripheral itself.

One thing I'd definitely consider is keeping the sensor, power, and communication wiring separated where possible. If the analog sensors share connectors or routing with higher-current paths, noise can sometimes show up as seemingly random communication errors.

For the external wiring, I would recommend locking Molex-style connectors because they reduce the chances of intermittent connections during handling and testing. Have you noticed whether the corrupted packets occur more often when the analog inputs are active or when the 12V supply is under load?