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
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
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
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
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
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.
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
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