Bug when starting a UART port with UART inversion enabled on STM32303 and STM32F722

[mlars.1]

Hello ST

I have a project where I need to start and stop the UART during runtime, and I have noticed a possible bug in the stm32f3xx_hal_uart.c file.

The issue is that when initializing the UART to use the UART_ADVFEATURE_TXINVERT_INIT parameter, the Tx pin goes high for a very short time (~10us). I suspected that it was because the inversion of the pin took place after the UART was started, and i did some digging in the HAL code.

 

By setting the breakpoints as above, i concluded that the signal that was on the Tx pin was high after UART_SetConfig was called, and it went low again after UART_AdvFeatureConfig was called. This seems to me that the pin goes high (UART Idle), before the inversion takes place (UART idle low after inversion).

The Tx pin viewed under an oscilloscope where the code is initializing and deinitializing the UART every ~100ms, resulted in a consistent voltage spike.

I tried to confirm my suspicion by swapping the order the two functions were called, so the inversion took place before setting the config, and that seemed to fix the issue.

To check if it was a hardware specific issue, i also checked on an STM32F722, and the behavior was the same.

Uart parameters used:

BAUD: 100000

Databits: 8

Stopbits: 2

Parity: even

Tx inversion: enabled

HAL version on stm32f303: V1.5.6

[waclawek.jan]

Please post content of UART_SetConfig and UART_AdvFeatureConfig functions.

Nevermind, I now see these are internal Cube functions. If was not clear to me that you're posting content of Cube files, not your code.

JW

[waclawek.jan]

Confirmed experimentally, that after setting USARTx_CR1.TE, the Tx pin starts to be actively driven to level given by USART_CR2.TXINV, regardless that USARTx_CR1.UE is not set. It means, that if the user choses to use TXINV=1, it must be set *before* setting USARTx_CR1.TE.

Swapping UART_SetConfig() and UART_AdvFeatureConfig() in stm32XXxx_hal_uart.c:HAL_xxxx_Init() functions (as well as in their hal_usart.c counterparts - btw. it's was a rather dumb choice to them separated, both in naming in the DS/RM and files/functions in libraries) as suggested above may have other interactions if some of the other "advanced features" is used, this ought to be meticulously researched. Maybe better, setting TXINV could be separated from UART_AdvFeatureConfig() and moved before UART_SetConfig().

@Amel NASRI​ , can this please be looked at and fixed, in all STM32 Cubes where this version of USART/UART (i.e. newer than 'F0/F3) is used? Thanks.

JW

[Guenael Cadier]

Dear @Community member​ , @mlars.1​ ,

I confirm your analysis, i.e. that current initialization sequence leads to the observed spike. I take the action point to raise the issue in ST to get this sorted out.

Regards

[waclawek.jan]

Thanks, @Guenael Cadier​ .

JW

[Amel NASRI]

For tracking purpose: Internal ticket number: 145958 (This is an internal tracking number and is not accessible or usable by customers).

[mlars.1]

Any updates on the issue?

[Guenael Cadier]

Dear @mlars.1​ 

Ticket is under processing, final update will be delivered into official STM32Cube packages.

Regarding the update to be performed for your use case (TX Inversion enabled), I confirm that your approach is the right one, i.e. invert UART_SetConfig() and UART_AdvFeatureConfig() function calls. We are checking if this could be applied to all configurations settings handled as "advanced".

Regards

[miroslav]

Hello,

I'm using stm32l476 and problem is a bit different. Cube package already have update from this discussion and that is fine. What is not fine is that RX stays low forever.

TX is inverted and that is fine, but RX is actively driven low so device from other side can't pull it up at all. I cut the line on PCB and controlled device pulls it up immediately so it is definitely regarding RX configuration.

Any thoughts on this?

Best regards,
Miroslav

[Tesla DeLorean]

Yeah, that seems very odd, double check how you're initializing the pin.

The peripheral shouldn't be putting the RX in push-pull mode.

Make sure to clear auto/local structures in subroutines as otherwise they'll contain random stack junk an other functions will misconfigure the hardware.