Effect of live wire insertion/removal of SPI signals

[shank]

Hello, I am looking for a solution to my problem.

I am using an STM32C031 to light LEDs using SPI signals.
I am using a connector to connect the STM32 mounting board to the LED mounting board. The connector connects the DC power supply and the SPI signals DATA and CLK of the STM32OUT.
When this connector is plugged or unplugged in several times, a phenomenon appears in which all of the connected LEDs blink abnormally. Verification of the waveform revealed that the waveform was abnormal at the SPIOUT of the STM32. This abnormal waveform cannot be corrected without turning the power of the STM32 itself on and off.
We investigated the possibility of correcting the problem programmatically and found that changing the SPI baud rate from 3 MBits/s to 1.5 MBits/s did not produce the abnormal waveform at the active wire insertion/withdrawal. However, I am not sure if this is a fundamental solution.
Is it possible that this kind of SPI baud rate setting changes the behavior when physical damage is inflicted?

Best Regards,

[Andrew Neil]

Maybe getting a glitch when the power is connected/disconnected?

Have you observed the MCU supply lines when this happens?

Are you able to connect a debugger in the "abnormal" situation to see what's happening?

If not, instrument your code to give output to a UART and observe what happens...

[shank]

Hi, Andrew.

Thank you for your answer.
You are correct. Perhaps this phenomenon occurs because the power or signal line is connected before the GND when connecting/disconnecting power.

When the power was turned on with the live wire plugged in and disconnected, there was a maximum voltage of about 7.5V where it normally operates at 3.3V.
The MCU is still working after the voltage reaches 7.5V, but Should we first design a circuit to suppress this voltage?

On the software side this time, the signal is received by USART, and the signal received by USART is changed to SPI to control the LEDs. When an error occurs due to live wire insertion/removal, unexpected blinking occurs, but the dimming control of the LED itself is controlled. Therefore, it is not that the MCU is completely broken, but that the blinking is added to the normal operation.
We have also tried debugging the program, but so far have only been able to confirm normal operation.

In order to observe what is happening in the UART, should I design it so that it outputs something when an error flag is raised?

Best regards,

[shank]

Postscript.

I found that the noise detection flag in the USART interrupt and status register (USART_ISR) is set to 1 when abnormal lighting occurs. Is it possible that an abnormal USART occurs when the noise detection flag is set to 1?

[Andrew Neil · Accepted solution]

More likely that your code doesn't properly handle the error condition, and that causes the code to misbehave.

If the USART is reporting noise errors, then you're likely getting corrupted data - so does your code do any error detection/correction?

If you feed garbage into your SPI control, then you're likely to get garbage out of it!

"GIGO" = Garbage In; Garbage Out

Also, if the USART is detecting noise, then it's likely that other parts of your system may also be affected by noise ...

You probably need to look at your supply (and other) filtering.

[shank]

Thank you for your response.
The abnormal lighting was GIGO-like data, so we decided to discard the data that had been received when the noise flag reached 1, lower the flag, and receive new data that does not raise the noise flag to be reflected in the SPI.
We will also review the circuitry related to filtering in the supply section so that the noise detection flag is not raised in the first place.

[Andrew Neil]

---

@shank wrote:

we decided to discard the data that had been received when the noise flag reached 1, 

---

That's a start, but it won't cover everything.

The USART noise detection won't detect all disruptions - you'll also need to have some sort of error check (eg, a CRC) in your comms.

---

@shank wrote:

We will also review the circuitry related to filtering in the supply section 

---

Not just the supply section; beware of noise also entering by other routes ...

eg, see: https://community.st.com/t5/stm32-mcus-products/uart-rx-pin-input-impedance-for-rc-low-pass-filter-design-stm32/td-p/686986