F401RE Nucleo UART_Printf example produces faulty formatted serial output bytes for ODD parity, but correct for parity NONE and correct when changing settings to 9 bits while receiver is at 8bits.

[Johi]

Hello,

During my exploration of the F401RE board, I tried to make the uart_printf example work correctly.

Capturing the output of the main MCU via CN3-RX pin to a PicoScope 5440, an CH340 and on board F103 USB interface MCU all lead to the same conclusion: the output of the main F401RE MCU on UART2 is not correctly formatted when using ODD parity.

When I use parity none or change to 9 data bits instead of 8 data bits (only change the MCU settings, the capturing settings remain at 8 bits), all seems to work OK.

Documented case with detailed data in attachment.

Any help most appreciated.

Johi.

[MM..1]

On old std libs code here is perfect comment , for use parity is required 9bit setup.

[Johi]

Thank you very much for the swift answer;

So I understand: if parity needed, select 9 bits, as per design?

1) This would imply that the demo is designed to fail as it combines 8 bits and odd parity? (It is the first demo I ran :astonished_face: )

2) Mega2560 and 16450/16550 support 5 to 9 data bits + parity bit + 1 or 2 stop bits. So this would then imply that ST MCU is unable to do start + 9 data bits + parity bit + stop bit(s)?

3) Table .168 in RM0368 points into your direction: bit 8 is indicated as a possible parity bit.

Johi

[waclawek.jan]

> 2) Mega2560 and 16450/16550 support 5 to 9 data bits + parity bit + 1 or 2 stop bits.

ST chose to count the parity bits up to the data bits, which is different from most UARTS there. I was a bad choice, but it is what it is.

> So this would then imply that ST MCU is unable to do start + 9 data bits + parity bit + stop bit(s)?

Yes.

JW

[Tesla DeLorean]

Your original example is correct for 7O1 as the total is 8-bit, you'd need to mask the read data on the STM32 side to removed the high-order parity bit.

The ST implementation saved them transistors/gates