MIMXRT1060-EVK LPUART: 7 dataBitsCount mode

[Lukaz]

Hello,

I was creating my own library for LPUART and after I was done I started testing it.
One case is to use a 9600 7E1 protocol. I use RealTerm as a serial terminal to send and receive the data to and from the UART. In this case, when the UART receives a character the frame error flag "FE" or the parity error flag "PF" in the STAT register is always raised, but RealTerm displays the data it receives from the UART correctly as 7-bit data. While I was tracking why this happens I came across this bunch of code in the fsl_lpuart.c file from the SDK

I have the following questions:

1. Why is the parity mode being checked again, wasn't it already set previously in the following line?

 temp |= (uint8_t)config->parityMode

 
2. According to the reference manual, the M7 bit in the CTRL register should be set to enable the 7-bit data mode. Why is it being cleared?

3. When I replaced this bit of code as follows (see below), the FE or the PF flag is still being raised, but this time RealTerm receives also corrupted data.

Can anyone help me figure this out?
Thanks in advance.

[Pavel_Hernandez]

Hello,

Could you tell me if I have the same configuration on the tera term? I will reproduce your case to get more details.

Best regards,
Pavel

[Lukaz]

Only the parity was different, I had even parity 

[Pavel_Hernandez · Accepted solution]

Hello,

A- I replayed the same issue as you reported but I think you misunderstand the parity even, I configure the LPUART with this data.
config.baudRate_Bps = 9600U;
config.parityMode = kLPUART_ParityEven;
config.stopBitCount = kLPUART_OneStopBit;
config.dataBitsCount = kLPUART_EightDataBits;

You need to take in count the parity bit, there are 7 bit of data + 1-bit parity in the transmission, I hope the image helps you to understand this.

B- The variable temp is a temporary container, this does not set the configuration to the register.

Spoiler

temp |= (uint8_t)config->parityMode | LPUART_CTRL_IDLECFG(config->rxIdleConfig) |
LPUART_CTRL_ILT(config->rxIdleType);

When the configuration is ready, temp is use to set the register like this [base->CTRL = temp;].

C- In your original configuration when you set with kLPUART_ParityEven the M7 is off in CTRL. The datasheet says M7 [0b - Receiver and transmitter use 8-bit to 10-bit data characters] for send 7 data + 1 parity, but have a conflict with the kLPUART_SevenDataBits.

Spoiler

if (kLPUART_SevenDataBits == config->dataBitsCount)
{
if (kLPUART_ParityDisabled != config->parityMode)
{
temp &= ~LPUART_CTRL_M7_MASK; /* Seven data bits and one parity bit */
}
else
{
temp |= LPUART_CTRL_M7_MASK;
}
}

Please let me know if I did understand your information or if you need more information please let me know, I hope this information will help you.

Best regards,
Pavel.

[Lukaz]

Hello Pavel,

thank you for your answer.
Now I understand where my confusion comes from, it is not about not accounting for the parity bit, but I thought the character length includes only the data bits, so with the 7-bit character length configuration (M7 = 1), I thought it automatically configures the frame as 7 data bits + whatever how many parity bits are configured.
Just to make sure I understand you correctly if we configure the character length as 10 bits, which is the longest, and we configure a parity bit (even or odd), that means 9 data bits + 1 parity and not 10 data bits + 1 parity, am I right?

Thanks again.

[Pavel_Hernandez]

Hello,

Yes, that's correct. Even if you need to review an example the SDK has the 9bit_interrupt_transfer.

Best regards,
Pavel