S32K146 LPUART Start bit

[raulcastanon]

Hello,

I'm using a development board S32K146 and working with the LPUART, i did the configuration using the SDK 8.5.
The configuration is:

Baud rate: 2400

Parity: even
Stop bits: 2

Data: 8 bits

8 bit data + 2 stop bits + 1 parity bit + 1 start bit

The communication is working using a terminal and a TTL cable. I watch the trace using an oscilloscope and a saw that there is something incorrect in the frame.
As message I've sent two 'A'->"01000001" this will throw a 0 as even parity bit.

As we can see in the image, I'm missing a bit in the trace and I think this will be the start bit

Using the reference manual I don't see any register where I can enable the start bit, neither in the SDK window on the S32DS.

Someone knows how to enable the start bit in the trace?

Thanks in advance

[jiri_kral]

Hi, 

it looks like that this is known LPUART limitation mentioned in Reference manual:

Anyway - I'll put feature request to SDK team for changing data size automatically by Processor Expert when parity is enabled. 

Jiri

[raulcastanon]

I got another one, 

After we change the configuration from 8 to 9 data bits, the first data byte is correct as you verify with the scope, but the SW got stuck in this function:

while(LPUART_DRV_GetTransmitStatus(INST_LPUART1, &bytesRemaining) != STATUS_SUCCESS)

Sending bytes in the bus.

welcomeMsg is only "AA"

What could be wrong? did I miss something?

The only change made was using the SDK changing data bits from 8 to 9.

Thanks in advance

[jiri_kral]

Sorry - I forgot add non SDK fix - 

just put

LPUART1->CTRL |= 0x10;

after 

LPUART_DRV_Init();

This set CTRL.M bit to 1 - 9 bit character length. Also don't forget set character length to 8 bits in Processor Expert and generate PE code. 

Jiri

[jiri_kral]

Hi Raul, 

I forwarded this thread to SDK team. Basically - with Parity enabled you need 9 bit data length where you don't care about 9th bit, but it can be done only with two bytes per character. Technically - it is nonsense, because you just need to use parity - nothing else. 

With current SDK I'm using as workaround this:

uint8_t datai[256];
for (int i=0;i<256;i++)
{
   if ((i%2)==0)
      datai[i]=0xAA;
else
      datai[i]=0x00;

}
LPUART_DRV_SendData(INST_LPUART1, datai, 256);

this allows me to send 128 bytes of data with parity... 

Hope the SDK team will have better solution - may be I overlooked something. 

Jiri 

[raulcastanon]

Hello Jiri, 

Thank you for your great support.

Maybe another request could be to re-write the register description, I think this could make it more clear if we add something about increasing the data bits when parity is enabled.

Thanks again.

Raul C.

[jiri_kral]

Hi Raul, 

First of all - thank you for report. The Parity bit is affecting last data bit on hardware layer. As workaround you can use data size 9 bits. In this case is parity working okay and terminal is happy. With 8 bit data size is lost MSb. I also checked EmbSys registers - and CTRL is set correctly. 

For testing I used 0xAA data and Odd parity - terminal received 0x2A - here is frame( Bit7 is overwritten by Parity)

Scenario with 0xAA and 9 bit data:

Jiri

[jiri_kral]

Hi, 

the start bit is not configurable - it must be always present. I tried your scenario - and it looks like that there is no Parity bit - even if it is enabled. I'll try to figure out what's going on and let you know.. 

Here is the same scenario with decoded frame: 

Jiri