USART2 on STM32L431 does not support parity with CubeMx

[po221]

Hello

I'm using a stm32L431. here the documentation :

https://www.st.com/en/microcontrollers-microprocessors/stm32l4x1.html#documentation

HSI is enabled at 16MHz for USART2, used to receive a 1200Bd signal (7bit data + even parity + 1 stop).

I receive wrong characters because of the trim. of parity

I already asked a question about the TRIM but that's not the problem

https://community.st.com/s/question/0D53W00001iwHrbSAE/how-to-trim-the-stm32-hsi-easily

I connect a USB converter (With FT232) on the RX of UART2 to send data to the stm32

I use CubeMx to configure UART2

>> Case 1 that works : (no parity)

Configuration by CubeMX :

 huart2.Instance = USART2;

 huart2.Init.BaudRate = 1200;

 huart2.Init.WordLength = UART_WORDLENGTH_8B;

 huart2.Init.StopBits = UART_STOPBITS_1;

 huart2.Init.Parity = UART_PARITY_NONE;

 huart2.Init.Mode = UART_MODE_RX;

 huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;

 huart2.Init.OverSampling = UART_OVERSAMPLING_16;

 huart2.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;

 huart2.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;

 if (HAL_UART_Init(&huart2) != HAL_OK)

Teraterm configuration :

I receive the data without fault...

>> Case 2 not working : (even parity)

Configuration by CubeMX :

huart2.Instance = USART2;

 huart2.Init.BaudRate = 1200;

 huart2.Init.WordLength = UART_WORDLENGTH_8B; // including parity

 huart2.Init.StopBits = UART_STOPBITS_1;

 huart2.Init.Parity = UART_PARITY_EVEN;

 huart2.Init.Mode = UART_MODE_RX;

 huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;

 huart2.Init.OverSampling = UART_OVERSAMPLING_16;

 huart2.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;

 huart2.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;

 if (HAL_UART_Init(&huart2) != HAL_OK)

Teraterm configuration :

Here I receive wrong things, part of the characters are correct, another incoherent

I know that the probability is high that the problem is between the keyboard and the chair but... I'm standing, without a chair! so it can come from a concern of HAL as for the TRIM which is strangely managed?

Thanks in advance

[waclawek.jan]

> Teraterm configuration :

Probably failed screenshot insertion? Try through uploading, on bottom of the editor window click on the "picture" icon.

Also, read out the USART registers content and check/post.

JW

[Tesla DeLorean · Accepted solution]

You will need to mask the parity bit off data read in such a fashion

ie int data = USART2->RDR & 0x7F; // mask down to 7-bit

[po221]

>> Case 1 that works : (no parity)

 

>> Case 2 not working : (even parity)

[po221]

I'm afraid to understand...

When using parity do we need to manually remove the parity bit?

Here I recover the data by the DMA ; I have to loop on all my buffer to delete the 7th bit of all buffer éléments ?

I'm testing...it would correspond well to the fact that some characters pass and others do not

[po221]

it's all good with less 7 bit, Thanks a lot

I think I've never had to fetch data on 7b before, maybe every uart in the world works like this; I wouldn't have suspected it for a second

[waclawek.jan]

Probably no other UART in the world works like this...

Glad you got it working. Clive (Tesla) is the local expert of all things weird... 🙂

JW

[Tesla DeLorean]

I shave with Occam's Razor...

I suppose they saved a bunch of transistors with this design. The holding registers are 9-bit wide, the DR reads/writes as a 16-bit value. I'd assume the TDR has logic in-front of it to selectively compute the parity bit, and the RDR has logic behind to selectively check, and you're left to mask the value you read. Makes for a simpler, orthogonal, design.

Makes sense to the IC/HW guys, less so the SW ones

[po221]

thank you

big stress on the starting point of my test

but I'm reassured, all my other tests (error, frame, frame analysis...) work perfectly.