FPGA shield uart test

[wajahat-abbas]

Description

The FPGA uart test case "9600, 8O1, FC on" enables the odd parity and then checks if data sent by tester is received correctly by DUT uart. This test passes for K64F however it is failing for Ublox C030 targets.
The C030 boards use STM32F4 as MCU and according to the reference manual of this MCU, when parity is enabled, the MSB of value read from Data Register includes the parity bit. So in case of this MCU, the test case should mask the value read with 0xFF before doing the comparison.

Please consider this example:
Tester wrote 0x04 on uart.
Value read from DR is 0x04, the comparison succeeds because in this case the parity bit is set to 0 as parity of data byte is already odd.

Now the written value is incremented:
Tester writes 0x05.
Value read from DR is 0x105, the test asserts here as 0x05 != 0x105 however this is happening because the value in DR includes the parity bit which is now set to 1 as parity of data byte is not odd.

I would also like to know if this behavior is observed for any other targets with ST MCU. I tried on Nucleo-F429ZI but it seems the Arduino header does not have CTS/RTS pins so this test passes with following message:
[1566299117.84][CONN][RXD] Could not find pins for UART testing

@RobMeades @MarceloSalazar @fahim-ublox @c1728p9

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[MarceloSalazar]

FYI @jamesbeyond

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1652

[0xc0170]

cc @ARMmbed/mbed-os-hal

[fkjagodzinski]

@wajahat-ublox Thanks for a detailed description. 👍

Looking at the ST HAL and the Table 146. of STM32F42xxx RM, I can see that the influence of the PCE bit on the actual number of data bits has been taken into consideration in serial_format() implementation:

mbed-os/targets/TARGET_STM/serial_api.c

Lines 426 to 455 in 590ce2c

	switch (data_bits) {
	case 7:
	if (parity != UART_PARITY_NONE) {
	obj_s->databits = UART_WORDLENGTH_8B;
	} else {
	#if defined UART_WORDLENGTH_7B
	obj_s->databits = UART_WORDLENGTH_7B;
	#else
	error("7-bit data format without parity is not supported");
	#endif
	}
	break;
	case 8:
	if (parity != UART_PARITY_NONE) {
	obj_s->databits = UART_WORDLENGTH_9B;
	} else {
	obj_s->databits = UART_WORDLENGTH_8B;
	}
	break;
	case 9:
	if (parity != UART_PARITY_NONE) {
	error("Parity is not supported with 9-bit data format");
	} else {
	obj_s->databits = UART_WORDLENGTH_9B;
	}
	break;
	default:
	error("Only 7, 8 or 9-bit data formats are supported");
	break;
	}

but serial_getc() seems to be missing this logic:

mbed-os/targets/TARGET_STM/TARGET_STM32F4/serial_device.c

Lines 271 to 275 in 590ce2c

	struct serial_s *obj_s = SERIAL_S(obj);
	UART_HandleTypeDef *huart = &uart_handlers[obj_s->index];
	while (!serial_readable(obj));
	return (int)(huart->Instance->DR & 0x1FF);

@LMESTM, @jeromecoutant, it seems we should update the serial_getc() implementation to make use of obj_s->databits for the bitmask calculation. Could you comment on that, please?

[wajahat-abbas]

@fkjagodzinski Yes i think both obj_s->databits and obj_s->parity need to be used to get the bitmask. obj_s->databits alone will only give total bit length (7, 8 or 9) and without knowing if parity is enabled or not we will not get the correct mask.

[0xc0170]

@LMESTM, @jeromecoutant, it seems we should update the serial_getc() implementation to make use of obj_s->databits for the bitmask calculation. Could you comment on that, please?

cc @ARMmbed/team-st-mcd

[jeromecoutant]

Please check #12611
Thx