LIN reception via master node - MPC5748G

[T-o]

Hello,

I’m trying to use the MPC5748G LinFlex modules to read the LIN bus without interfering with it (making it act like a sniffer of some sort).

For testing I am using the NXP Motherboard with the MPC5748G bga324 package on the daughter card.
As per my understanding there are 16 modules (with LinFlex 0 being able to do Slave&Master+DMA, LinFlex1 Master only + DMA, and then the rest being Master only without DMA).

My goal is to read the LIN bus with the master nodes (as I need multiple readers/listeners).

With the LinFlex1 in master mode I’ve tried to read/detect the LIN communication without it sending the header sequence but to no avail.
I started implementing a bit banging routine to handle the reception manually, but the transceiver is acting up on the delays when trying to transmit through it via the Tx pin.
And it also doesn’t replicate the Lin bus state on the Rx pin so I cannot manually sample the bus through the transceiver in order to avoid using another level shifter.

Searching the forum pages, I found a couple topic with similar subject but no solutions.

I would like to know if there is a way to force the master node registers to have written to them the data passing through the LIN bus.

Thank you

Théo

[PetrS]

Hi,

if you want to implement a "sniffer", nothing need to be sent, you just need to receive/read LIN frame data and process/analyze them somehow. So not sure of your bit bang implementation. On sniffer node you should have TX pin held high still.
Anyway you cannot receive unknown payload using LINflexD module, definitely not in Master mode, but neither in Slave one. On LIN systems this must be know in advance, during system specification, thus the ID specify payload, direction, CCS.
You will need to simply detect break and then receive each byte using UART mode and post-process the data manually to interpret the payload and CCS.

BR, Petr

[T-o]

Hi Petr, 

First of all, please accept my apologies for the delay in getting back to you — I appreciate your help and your detailed response. 

Following your advice, I’ve been working on setting up the LINFlex module in UART mode. I'm currently using the uart_pal example code as a base. 

I do manage to receive most of the LIN frames this way — especially the ID and DATA bytes — but I don’t see the sync byte and the checksum byte appears to be corrupted. When I check the reception status, I see the uart_framing_error flag set, and I get unexpected blank bytes in the reception buffer between frames. This makes parsing a bit tricky, and I wonder if I'm missing some configuration details specific to this use case. 

So far, I’ve been using 8 data bits, no parity, and 1 stop bit. Are there any specific UART settings (baud rate tolerance, stop bits, parity, etc.) I should be aware of when configuring the LINFlex module for LIN sniffing in UART mode? 

One hypothesis I have is that the break field is causing some of the blank bytes. Is there a recommended way to reliably detect the break field in this mode? 

Also, do I need to manually synchronize to the LIN frame boundaries after each break, or is that already handled by the module? 

Any additional guidance on cleaning up the reception or on the post-processing would be greatly appreciated. 

Thank you again for your time and support. 

Best regards, 
Théo 

[PetrS]

Hi,

with normal 8N1 UART config the break should generate frame error. You should take this as start of LIN frame (break), within error interrupt clear error flags and release buffer by RMB if flag is set. Next bytes should be received normally then.

BR, Petr