7-bit data length with (even/odd) parity is configured as 8-bit in UART

[RadhikaMaheshwari-eaton]

Hello people,

I have an observation regarding UART while using STM32H743ZI nucleo board with Zephyr3.2.0 and Zephyr SDK 0.15.2:
Case 1- When I am configuring 7-bit data length with even/odd parity it is configured as 8-bit. We are getting the correct parity, but 7-bit is not getting configured.
Case 2- While setting up 7-bit with none parity it is considered as 7-bit but not getting the correct response (garbage value).

I think it is related to the function uart_stm32_cfg2ll_databits in the file uart_stm32.c

Note: baudrate=115200 and usart3 peripheral
What I can deduct from this situation is, if we send 0x55 the uart data register gets the correct value but in response we get 0 byte in return. The CR1 (control register) have values for word length M1 (bit 28) & M2 (bit 12) :
Case 1- CR1->M[1:0] = '10' 1 start bit, 7 Data bits, n Stop bit

Case 2- CR1->M[1:0] = '00' 1 start bit, 8 Data bits, n Stop bit

Would like to know your thoughts on this.

[RadhikaMaheshwari-eaton]

Hello people,

FYI
uart_fifo_read is receiving byte correctly but if we error check by uart_err_check then there is uart framing error whose value is 4

[prayassamriya]

@gautierg-st do you have any advice on this issue?

[gautierg-st]

Hello,

If you want to send 7-bit data + 1 parity byte, it is expected that your USART is configured as 8-bits as you are indeed sending 8 bits total (though I completely understand why it could seem counter-intuitive at first). It is perfectly summed up in the following table (found in RM0433):

And also in this diagram:

@RadhikaMaheshwari-eaton In which case do you see the framing error? What configuration are you using?

[RadhikaMaheshwari-eaton]

Hi @gautierg-st

In the beginning we were trying to send and receive some data with 7-bit and none parity, then we noticed that Framing error (FE) bit was set before the main() so we reset the board (H743zi) 7-8 times but at one point we long pressed the reset button and start the debugging simultaneously. FE got cleared and we were able to communicate (data send -> FA and received data -> 7A as expected).

Testing more on that we have few more observations:

• few cases where FE is being set before main()
• but it got cleared in some cases and communication works
• in some other scenarios we are sending ASCII characters but not getting expected response in echo

We are investigating more on register values before main (in reset handler) and after main(), will share those observations soon.

[erwango]

@RadhikaMaheshwari-eaton Did you made some progress in the investigation?
Is the issue still valid?

[RadhikaMaheshwari-eaton]

@RadhikaMaheshwari-eaton Did you made some progress in the investigation? Is the issue still valid?

Hi,
My teammates are currently working on this and will update you on the progress as we move forward. Yes, it is still a valid issue.

[erwango]

My teammates are currently working on this and will update you on the progress as we move forward. Yes, it is still a valid issue.

Thanks for the update

[RadhikaMaheshwari-eaton]

@erwango
I want to know if Zephyr driver supports 7-bit data with none parity in UART for STM32H743.

[erwango]

@erwango I want to know if Zephyr driver supports 7-bit data with none parity in UART for STM32H743.

There is nothing preventing to perform this configuration.
Though, we are missing tests to validate the complete set of existing combinations, so there is a possibility that bugs are present in some specific combinations