MPC5748G 9 bit frame uart mode

[bonzo]

Issue:  9-bit frames with MPC5748G solution or work-around?

Message from customer below

--Brad

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

In some of our communications using the MC9S12XDP512 processor we use the 9-bit frames of the UART for RS-485 communications.  Below is some documentation regarding this feature for the MC9SXDP512 processor.  In 9-bit frame mode the 9^th bit can be configured as a parity bit or data bit.  There are registers that can be accessed for the transmit and receive of the 9^th bit that are easy to access by software.

In porting the software from the MC9S12XDP512 processor to the new MPC5748G processor the documentation for the MPC5748G states that the core supports 9-bit frames, but then states that the ninth bit should be a parity bit (page 1931 of the MPC5748GRM.pdf, version 4 document).

Question:  When sending data, it is possible to force a bit of 0 or 1 for the parity bit through the PC[1:0] bits of the LINFlexDx_UARTCR register; however this requires going into initialization mode which is in a different register for changing the UART bit value every time the bit needs to be changed for transmitting data.  Below are the control bits of the LINFlexDx_UARTCR register for setting the 9^th bit value.

In regards to receiving data from the UART for 9 bit frames there doesn’t seem to be anyway to examine the bit value of the parity bit (9^th bit) but in the MC9S12XDP512 processor one can.  The LINFlexDx_UARTSR has the PE bit flags that indicate a parity error for received data.  It would be helpful if these bits could be configured to give the 9^th bit value instead, perhaps.

For such a high powered processor I’m a bit surprised that the parity bit cannot be used as a data bit in 9-bit frames.    Freescale processors supported this feature in the past and so do other chip manufactures as well.

For our purposes I think we can make the current UART hardware for the MPC5748G processor work for our application, but I wanted to comment to NXP about this issue as this core is really impressive.

[lukaszadrapa · Accepted solution]

Hi,

your observation is correct. This is how it works on MPC5748G.

Switching to initialization mode doesn’t make sense, so it will be necessary to find another workaround.

For example:

UART mode supports 16bit data frame. You can use only first 9 bits to fill the date and the rest of data bits force to ‘1’. Then it will transmit:

start bit + 9bit data + the rest of the data bits (all ‘1’) + stop bit

For the device on other side, it will look like 9bit data frame. There will be just certain delay between the frames when all the remaining ‘1’ are sent in the frame.

Regarding the receiver – if you can ensure that device sends frames to MPC5748G with sufficient delay (length of 8 data bit, at least) then you can use the same method. The receiver on MPC5748G will receive 9bit frame and you will see that bits in the rest of frame are all ‘1’.

If you can’t ensure that there’s sufficient delay between the frames, it will be necessary to emulate the receiver by software. I can see two options:

1. Connect RX signal to a pin that supports external interrupt. Once falling edge (start bit) comes to this pin, interrupt will be triggered. In this interrupt, disable the external interrupt and start a timer that will trigger another interrupts which will be triggered in the middle of each data bit. Sample the input pin in each timer interrupt handler. Once all bits are sampled, disable timer and enable external interrupt again.

2. Second option is the same as above but you can use timer to trigger DMA transfer to sample the input pin. Once all samples are taken, DMA can trigger interrupt which says that new frame is already available.

Regards,

Lukas

[ada_lu]

Hello, bonzo

Seems this is not a question on i.mx chip for MPU space.

Any comments?

B.R.

Ada

[bonzo]

The main page for MPU support says iMX and Vybrid.  I believe MPC5748 is a Vybrid.

[karina_valencia]

HI bonzo​, this  is not a Vybrid part.  Can you remove the  customer name? Then let me know to move it to  S32 Automotive Processors  where  TIC  team will support it.