CAN Stuff Errors at 500kbit/s on MPC5748G - FXOSC vs FS80 Clock issue

[Alex26]

Hello everyone,

I'm currently working with an MPC5748G board and trying to establish stable CAN communication at 500 kbit/s using S32 Design Studio for Power Architecture and the SDK 3.0.0. 
I develope in an example project (flexcan_mpc5748g). There is a generated clockMan1.c. 

Here's the bit timing configuration I'm using:

flexcan_time_segment_t ts = {
.propSeg = 6u,
.phaseSeg1 = 7u,
.phaseSeg2 = 2u,
.preDivider = 4u, 
.rJumpwidth = 2u
};

This results in 16 time quanta, a sample point of 87,5% and - assuming a 40 MHz CAN clock- a bitrate of exactly 500kbit/s.

When sending frames from a Vector VN5650 (500kbit/s, SP 87%), I consistently observe stuff errors at bit positions 5 and 7. 

In the original clockMan1.c, the clock source was set to ac9_sc = CGM_FLEXCANx_Source_FS80, meaning it was sourced from FIRC(?)
I changed it to ac9_sc = CGM_FLEXCANx_Source_FXOSC. 
I further changed .sysclk = CGM_SYSTEM_CLOCK_SRC_PLL_PHI0 to ...SRC_FXOSC. (drun)

The original clockMan1.c worked with the following configuration at ~210kbit/s:
flexcan_time_segment_t ts = {
.propSeg = 6u,
.phaseSeg1 = 7u,
.phaseSeg2 = 2u,
.preDivider = 9u,
.rJumpwidth = 2u
};

When I calculate with this configuration and 210kbit/s, I get a 33,6MHz clock. (I don't understand, why the board is running on 33,6MHz if my calculation is right.)

I attached my main.c and the current clockMan1.c. 

So, my questions are:
Am I doing a mistake in the calculation of the baudrate? Is my idea of how the clockMan1.c works, wrong?

I'm new to this topic and apologize in advance if I'm missing something obvious.
I’d really appreciate any guidance or tips!

Kind regards

[PetrS]

Hi,

CAN PE clock is derived either from FXOSC or F40 depending CTRL1[CLKSRC] bit setting

If you select FXOSC as system clock then F40 will be less that CAN PE clock which is not possible. You need to have config where CHI_CLK/BIU_CLK is not smaller the CAN PE clock

So be sure your CAN PE clock is properly set and you know its freq, so CAN bit timing can be calculated and set. If you are using below

flexcan_time_segment_t ts = {
        .propSeg    = 6u,
        .phaseSeg1  = 7u,
        .phaseSeg2  = 2u,
        .preDivider = 4u,
        .rJumpwidth = 2u
    };
    FLEXCAN_DRV_SetBitrate(CAN_INSTANCE, &ts);

those values are written to respective register field. But actual value is propSeg+1 etc. So your calculation should respect that, and yours is wrong.

CAN bit rate = PE clock / [(PRESDIV+1) * (1 + PROPSEG+1 + PSEG1+1 + PSEG2+1)]

BR, Petr

[Alex26]

Hi,

thanks for your useful reply and the correction of the calculation!

I calculated the PE Clock for the config, that worked at ~210kbit/s with the original clockMan1.c again. 

210.526 * ((9[preDivider] + 1) * ( 1 + 6[propSeg] + 1  + 7[pSeg1] + 1 + 2[pSeg2] + 1)) = 40 MHz

So my clock was already 40Mhz using the default clockMan1.c. 

I've undone my changes and tried to find a new bit rate config. 

40 MHz / ((4 + 1) * (1 + 4 + 1 + 7 + 1 + 1 + 1)) = 500 kbit/s and a SP at 87,5%.

Why does it still deliver Stuff Errors at bit position = 7. 

(These values fit with the borders of the flexcan_driver.c.) 

Thanks for your patience!

Kind regards

[PetrS]

Hi,

this really looks like bit timing issue, but revised calculation looks right.
I can recommend to simply send message from MCU and measure generated frame on TXD/RXD/CAN lines with scope/analyzer, to be sure right bitrate is used. Do it with and without CAN tool connected.
If having issue still share simplified project.

BR, Petr

[Alex26]

Hi PetR,

thanks again for replying. I analyzed the CAN Frames back then with a Logic Analyzer 8 from Saleae and did it again. The part I can't explain is that the MCU only sends valid CAN frames when using this specific configuration:
flexcan_time_segment_t ts = {
.propSeg = 6u,
.phaseSeg1 = 7u,
.phaseSeg2 = 2u,
.preDivider = 9u,
.rJumpwidth = 2u
};
When I flash other configuration, like the 500kbit/s config I showed in my last message, it doesn't transmit any meaningful frame at all.
I've attached two Saleae captures along with my minimal main.c, which simply sends CAN frames periodically.

I truly appreciate your support!

BR, Alex

[PetrS]

Hi Alex,

what is the board you have? What is the CAN transceiver used? Is the measurement done with board disconnected from bus, but locally terminated? It could be fine to add TXD/RXD pins as well, if possible.

BR, Petr

[Alex26]

Hi PetR, 

I am apologyzing for the missing information. 
I work with the DEVKIT-MPC5748G and use the integrated CAN Transceiver (A104463). The measurement was done with a connection to the Vector VN5650 via CAN. The Vector was measuring aswell. As you can see at the png LogicAnalyzer, he sent ACK. 
I measured now at CAN with the board disconnected from the bus and the output is the same as shown in the png's, of course with exception of the ACK. 

I measured now aswell the TXD pin with the working bit config. It shows the same frame, but the first bitrash is 1.5-2 µs longer than the same bitrash measured at CAN. 

The 500kbit/s config shows at the txd pin no senseful frame either. But here are also the frames about 1.5 - 2 µs longer. 

About the termination topic: There is a jumper at the board. If I stick it in, I can see absolutely nothing. Only works, when I don't plug it in. 

I hope, I wrote it understandable. 

Thanks again for the help!

BR, Alex

[PetrS]

Hi Alex,

OK, let me test it on DEVKIT-MPC5748G (assume revD1) once I get it, hope tomorrow.

BR, Petr

[PetrS · Accepted solution]

Hi,

this is a result I got with SDK303 flexcan demo example. I used configuration from example

and have PCAN USB Pro connected with below setting

I see no issue in communication and this is measurement done on CAN_L, TXD and RXD pins

1. message sent upon SW button press

2. message received from PCAN

3. message sent upon SW button press, bus disconnected, but board terminated. Message transmitted still as there is no ACK

4. message sent upon SW button press, bus disconnected, but board not terminated. Message cannot be transmitted at all, bit error detected, error frames sent

So I got very expected results.

BR, Petr

[Alex26]

Hello PetrS,

I'd like to thank you again for your comprehensive help and the detailed documentation. My second board has arrived in the meantime, and everything works as desired on it. The exact same project runs on the new board, while it throws Stuff Errors on the old one..

Best regards, 
Alex