SIO spurious IRQs on STM32 USARTv3 when no callbacks/events enabled Topic is solved

[alex31]

Hi again, another bug encountered while wanting to make SIO work with DMA (so without need of ISR in a first time)

Bug: On STM32 USARTv3 SIO LLD, sio_lld_update_enable_flags() does not clear USART_CR1_RXNEIE_RXFNEIE. As a result, RXNE/RXFNE interrupts can remain enabled even after sioWriteEnableFlagsX(..., SIO_EV_NONE), causing spurious SIO IRQs (and the “spurious interrupt” assert) when no callback is configured.

Trigger: Typical sequence is:

1. sioStart(&SIODx, ...)
2. sioWriteEnableFlagsX(&SIODx, SIO_EV_NONE) (or no callback + no events enabled)
3. USARTv3 still has RXNEIE/RXFNEIE set → IRQ fires with no enabled events : spurious ISR assertion

Proposed fix (USARTv3 only): Clear RXNE/RXFNEIE in the CR1 mask before re‑applying enabled flags.

Code: Select all

 /* in USARTv3/hal_sio_lld.c::sio_lld_update_enable_flags() */
  cr1 = siop->usart->CR1 & ~(USART_CR1_IDLEIE | USART_CR1_TCIE |
                             USART_CR1_PEIE  | [b]USART_CR1_RXNEIE_RXFNEIE[/b]);

Note: USARTv2 LLD is already correct — it clears USART_CR1_RXNEIE inside its sio_lld_update_enable_flags().

And a SIO related question : I see that idle line detection is handled by SIO, but what about RTO (configurable receiver timeout), is it usable in the actual state of the driver ?

Alexandre

[Giovanni]

Hi,

RTO is not supported yet, it would require a new field in the configuration structure and some "handling" in the driver. It would also require some kind of new event which would be non-standard (defined in the LLD).

BTW, you can handle timeouts using virtual timers easily.

Giovanni

[alex31]

BTW, you can handle timeouts using virtual timers easily.

Yes, for now, I use virtual timers, but I think RTO would be better for my use case :
I use SIO + half buffer DMA, and I want the half buffer ISR to be triggered in case of configurable time silent on the line, so if I face very long message, I don't miss any bytes, but as soon as the transmission end, I can manage the end of transmission.

virtual timers can handle a global timeout on the entire transaction, not on the time since the line is silent.

I will give idle line detection a try, not configurable as RTO, but it seems to be handled.

Alexandre

[alex31]

using idle line detection work for my dma double buffer use case, but I hit another bug that has triggered spurious interrupt :

after an IDLE event the code unconditionally re‑enables RXNE/RXFT interrupts “for first char after idle”. If SIO_EV_RXNOTEMPY is not enabled, this
creates unwanted RX interrupts (especially with DMA where RXNE can clear before the ISR reads it), leading to isr == 0 and the “spurious interrupt” assert.

I have fixed my problem this way : re‑enable RXNE/RXFT only if SIO_EV_RXNOTEMPY is enabled.

But, I' am not confident that is this the right way to do it, I lack a good understanding of the intrinsic of this module.
Nonetheless, I attach my patch, as information.

Alexandre

[Giovanni]

Hi,

That code is currently disabled in trunk, do you think it is required and needs patching?

I applied the patch and re-enabled the code in meanwhile.

Giovanni

[FXCoder]

Hi,
That special NONEMPTY pseudo value is for MCUs with large FIFO (e.g. H7).
One eighth of an H7 USART FiFO is 2 characters so in a use case with char by char input (like shell console) there is no input on each keystroke if a FIFO threshold is used.
The line idle takes care of re-enabling the RXNEIE_RXFNEIE IRQ.

In the case where DMA is used then using RXFTCFG_FULL in the config should give no IRQs.
DMA will empty the USART RX quickly and the threshold will never be reached.
Not sure what the expected treatment of DMA is so I could be off topic here.

[alex31]

Hi,

That code is currently disabled in trunk, do you think it is required and needs patching?

I mainly use stable, but I ran tests with trunk@17672.
All tests are now passing in:

buffered mode (SD-like)

single-shot DMA (UART-like)

continuous half-buffer DMA

I think the issue I had was caused by incorrect use of sioGetAndClearEventsX() together with DMA.
It now works reliably without the sio_idle_path_guard patch.

I wrote a C++ wrapper (base class + three derived classes: buffered, continuous, datagram) that covers my use case:

https://github.com/alex31/chibios_enac_various_common/blob/master/sioWrapper.hpp

Not sure what the expected treatment of DMA is so I could be off topic here.

In both DMA modes I am only interested in the IDLE event, so that I can:

terminate the transaction in datagram mode

call the half-buffer ISR with an incomplete buffer in continuous mode

When listening to a continuous stream with unknown message length, the continuous class is the best fit.
However, I also tested the datagram (USART-like) class together with the UART hardware FIFO.
By looping on single-shot transactions, the FIFO accumulates incoming bytes between DMA transfers, and even at 1Mbaud I do not lose bytes.

In my case SIO solves a specific problem: I have a device that can assume different roles on the same USART, and I can select the most suitable mode at runtime.
This is not possible with SD or USART drivers, but it is with SIO.

Thanks Giovanni for this driver.

A.

[alex31]

To resume, I think this patch is necessary for stable, but not for trunk. Since trunk's HAL will be backported to stable, do not bother with this patch.

A.

[Giovanni]

So, can I close?

Giovanni

[alex31]

So, can I close?

For this patch : sio_idle_path_guard.patch.zip, it's not useful on trunk, but for this one : sio-fix_no_isr.patch.zip I thought it was applied, and just check that it is not. I will redo check tomorrow with assert enabled to confirm if it's needed or not in trunk.

A.