MPC5748G Receiving CAN frames with DLC>8 in non CAN FD mode

[danielnäslund]

I have taken over ownership of a MPC5748G code base. The drivers are written from scratch.

The CANPort driver seems to mostly work ok. I can connect 8 can ports and send and receive at 250kbits/s for hours with high busload.

But with one particular old in-house board (not a MPC5748 board) connected, I receive CAN frames with DLC = 15 when I power up the old board.

When I inspect the can traffic, I don't see any can frames with the matching ID. The ID and DATA seems to be roughly the same each time. Here's one occasion:

And here's another. The ID is the same but the DATA is not exactly the same.

Questions:

1. Can it be that my receive ISR is not properly locking the message buffer so that it gets partly overwritten? Not sure why it would only happen when I power up that other board.

2. Do you see something wrong with the init and receve functions in the attached code? I've tried to distill it down to it's essence. Those are the functions that do run, but I've removed some other code.

3. I noticed that SRR=0 when I receive the interrupts with DLC=15, but SRR=1 for the interrupts with ok can frames. Is that a clue?

[danielnäslund]

Hi Petr,

The CAN frame the MPC5748 receives on the RX pin does have DLC=15. But only 8 data bytes. I guess my logic analyzer decodes the frame based on the DLC number.

The ID, flags, DLC and 8 data bytes matches what I see in my debugger.

I was suprised that the FLEXCan controller accepts DLC>8 but according to https://www.kvaser.com/about-can/can-dictionary/ it is allowed for the DLC to be in the range [0, 15].

DLC – Data Length Code. A part of the CAN message. It used to mean simply the length of the CAN message, in bytes, and so had a value between 0 and 8 inclusive. In the revised CAN standard (from 2003) it can take any value between 0 and 15 inclusive, however the length of the CAN message is still limited to at most 8 bytes. All existing CAN controllers will handle a DLC larger than 8.

Question

1. Is it correct that the FLEXCan is expected to accept can frames with 8 data bytes but DLC > 8 ?

2. I've been asked by my colleague to ignore frames with DLC > 8. Is that a reasonable thing to do? Or can we always rely on the frames being valid if they're passed to our ISR?

3. Is there a register for reading the RX CRC? I've found the TX CRC, but not a corresponding one for RX.

[PetrS · Accepted solution]

Hi,

1) yes, for Classical CAN message format the DLC can be higher then 8, but it is taken as max payload (8 bytes).  So for received message, 8 bytes and received DLC are stored.

2) if the received message is acknowledged (seen on TX line), it was received without error, and if matching was successful, the message is moved into MB and MB flag is set (interrupt called). Thus you got a valid message and you should read it out.

3) no, there is no register for received CRC.

BR, Petr

[PetrS]

Hi,

so the given code is running on some board (not MPC5748G board) and after powering this board, the MCU is getting a receive interrupt, even if you do not see any message on the bus. What is the MCU used on this board? Do you see anything on module TX/RX pins before entering ISR?

1. the ISR routine looks normal, I think. Just use register access for clearing a flag, otherwise other flags can be cleared too if set, so use 
// 4. Acknowledge the proper flag at IFLAG registers
Port->IFLAG1.R = RxIRQBit;

2. The start of init function could be different. Depends on FZR/HALT bit setting, if cleared module will run after you enable it. Try to use e.g.

Port->MCR.B.FRZ= 1; // allow enter freeze mode
Port->MCR.B.HALT = 1; // enter freeze mode
if(Port->MCR.B.MDIS == 1) Port->MCR.B.MDIS= 0; // if disabled, enable module
while (!Port->MCR.B.FRZACK) {} // wait for freeze acknowledge to set

Port->MCR.B.MDIS = 1; // disable module before selecting clock source
while (!Port->MCR.B.LPMACK) {} // wait for low power acknowledge to set
Port->CTRL1.B.CLKsrc=1; // use peripheral clock
Port->MCR.B.MDIS = 0; // enable module for config
while (!Port->MCR.B.FRZACK) {} // wait for freeze acknowledge to set

// now set CAN bit timing, init MBs, etc

Be sure MCR[IRMQ] is cleared too, otherwise individual masking scheme is used and so RXIMRs should be initialized too.

3. SRR should be set when transmitting extended frame 

BR, Petr

[danielnäslund]

Thank you Petr for your reply.

I've added your suggested changes to the init function and the isr. I can still reproduce the problem.

I've probed the TX and RX lines between the MPC5748G and a CAN tranceiver. When the ISR receives a frame that has DLC > 8it it enables a gpio (isr_cond) which I use as trigger. m2_v is the supply voltage of the other board that sends the CAN frames.

For this frame, the debugger reports these values

I'll connect a logic analyzer (my Siglent SDS1104X-E scopes CAN decoder is a bit flaky) and I'll try reducing my code further.

Thank you,

Daniel