My team and I recently spent a few hours chasing what we were sure was a hardware noise problem. It turned out to be something much smaller.
The symptoms
The system started generating random Hall sensor interrupts. Two things made it hard to investigate:
- The Hall sensor was sealed, so we couldn't probe or inspect it directly.
- The interrupt line was shared between two Hall sensors, so we couldn't even tell which one was firing.
Was one sensor failing? Was something leaking onto the line? Was it EMI? Everything pointed towards a hardware problem.
The turning point
Then we noticed something: the false interrupts happened much more often while we were sending debug logs over UART.
Our UART debug TX was on PA9. On this STM32, PA9 also carries the UCPD1_DBCC1 function, part of the USB Type-C Power Delivery (UCPD) peripheral. With the UCPD block enabled, the DBCC1 configuration activates an internal USB-C dead-battery pull-down (Rd) on that pad. "Dead battery" support is what lets a USB-C sink device advertise itself to a charger even before its firmware is running.
That internal analog path ended up influencing the same net we were using for the Hall sensor interrupt. In other words, every time we printed a debug message, we were unintentionally poking our own IRQ line.
The fix
Once we knew where to look, the fix was a configuration change: making sure the dead-battery behaviour was not active on the pins we were using for other functions. On many STM32 families with UCPD, the HAL provides a dedicated call for this (for example HAL_PWREx_DisableUCPDDeadBattery()), but the exact mechanism differs between families, so check the reference manual for yours.
Lessons learned
- Read the full pin description, not just the function you selected. The datasheet's pinout table lists additional and analog functions that may be active by default after reset.
- Look for correlations. "It gets worse when X happens" is often the fastest route to the cause. Here, UART activity was the clue that broke the case open.
- Don't assume hardware first. In the end, it wasn't the hardware, it wasn't EMI and it wasn't the sensor. It was a small configuration detail we had overlooked.
And that's usually how these bugs end.