STM32WLE5CC Uart RX Interrupt Enable/Disable in Highly Noisy Hazard Environment

[DBhut.1]

Hello,

Our Device will be going to very Highly Noisy Hazard Environment Industry, We want to make sure device will work in any situation, STM32WLE5CC is End-node with Lorawan and Multiple application functionalities like RTC, Display etc.

In this environment, if Uart RX interrupt is enabled, then it may arise many unwanted interrupts, which can affect our device functionality.

Could you please suggest us is above statement is true?

Should we keep this Interrupt Disable in this environment?

any other suggestion to keep device functionality safe in this enviornment.

Thank You

[Paul1]

I develop systems for ships, lots of noise, it can be "fun" LOL. Developed style over decades that results in reliable installs on first try. Basic guidelines:

1. Recommend protecting in hardware first.

1a. Use shielded cables (Shield connected at only one end of any string of devices to prevent ground loops)

1b. Use appropriate transceiver ICs that are band width limited to ignore spikes above your data rate.

1c. Choose an appropriate datarate, i.e. slower will allow better hardware filtering of noise. (Do you really need megabit data?)

1d. Design your power and cabling to prevent ground loops which will amplify noise effects.

1e. Choose a balanced interface, such as RS-422 or RS-485 (Not direct UART signals or unbalanced RS-232).

2. Consider not using Rx Interrupt

2a. Use a timer interrupt to check for Rx Data at a sufficient rate to prevent overrun for all UARTs used, this will ensure there aren't excess Rx Interrupts that could halt your CPU. i.e. for Data 8N1@19200bps = 10bits/char(s01234567S) = 1920Hz or faster interrupt should ensure no overruns.

3. Ensure your protocols use appropriate protection (Choose devices that have appropriate protocols).

3a. Packet Checksum like CRC16 or CRC32 (not parity per byte)

3b. a protocol that can survive data dropouts/insertions: Suggest a "Stuffed" protocol with Start/End and stuffing characters (i.e. DLE Stuffing where you replace restricted characters STX/DLE/ETX in data field with DLE+ModifiedCharacter, such that if you see Start character you are confident it is a new packet and can immediately resynchronize any data stream). Personally I use [ ^ CR characters so I can use a normal terminal program to easily view packets.

Above mostly for cable connected devices. If your devices are "on board" and you have noise issues you will need to Redesign your PCB

- outer ground planes, appropriate decoupling capacitors at all IC power pins, Power sources, etc.

- Small chance that a shielded enclosure would reduce noise, but it probably won't fix a poor PCB design.

Paul

[DBhut.1]

Thanks for this suggestion,

Uart is used for debugging and configuration purpose only, no external peripheral or device is connected to it.

Could disabling RX interrupt and enable it only when needed make sense in this case ?

[Paul1]

Yes. Depends on your implementation.

Possibly: If you have a terminal program

• Set Rx as not interrupt
• Poll for Rx.
• Use manual typing or slowed data to enter a command/code/password to unlock fast mode
• Enable Rx Interrupt when fast mode properly requested
• Disable Rx Interrupt when any of (fast action completed, or inactivity timeout, or excess errors).

Paul