I'm working on CAN FD transciever using the S32K148 MCU. I already have both CAN and CAN FD functionality working. I however encountered the following problem.
I want to send periodic (500 ms) CAN FD message on the CAN2 module of the S32K148. The bus members are our custom PCB with S32K148 and Vector CAN/LIN Interface. I'm using Vector CANAlyzer to interpret the communication.
I'm using the 8 byte data length (implicitly for CAN 2.0B and set in the CAN2->FDCTRL[MBDSR0] for CAN FD). I'm using message buffers 0..15 for reception and 16..31 for transmission. Value of the CAN2->MCR[MAXMB] is 0x1F. This setup is the same for standard CAN and CAN FD.
Now I want to transmit the periodic message. First, using the standard CAN, there is no problem at all, the first TX MB (16) gets written every 500 ms and I see the desired CAN message in CANAlyzer.
When I setup the CAN2 module as CAN FD and again, I write the TX MB every 500 ms, I see the data are written in the correct MB RAM cell, however the MB CODE value remains 1100b (DATA - MB is a Tx Data Frame) and the MB TIME STAMP does not change. It seems as if the arbitration process didn't care for the MB ready to be transmitted.
I managed to overcome this problem in the following ways:
Thank you for advice!
to anyone stumbling here. I didn't find out, why MB16 won't transmit CAN FD frame, but MB15 will. However I managed to solve this. So here's for anyone wondering:
In my original setup, I was using apx. 1/3 of the 32 MBs for receiving standard ID frames, 1/3 for receiving extended ID frames and the rest was reserved for transmission. This was obviously stupid, as you only need a single MB for transmission at any given time (if you're using some sort of a circular buffer for storing frames to be sent and check the TX MB availability before writing it). So I configured MB0 for transmissio, than the even MBs of the rest to receive standard and odd MBs to receive extended ID frames. This way, if the upper half of MBs wont work for any reason, I will still be able to receive standard and extended ID frames and transmit them as well.
I also found out that unlike standard CAN, CAN FD is EXTREMLY sensitive to being properly terminated. With standard CAN, I was able to communicate only between my ECU and Vector CANCase (USB connected to PC running Vector CANAlyzer software). For CAN FD communication to work this way, I had to connect another ECU with CAN termination.