Problem with FlexCAN sample program from "Ver 1.0 of Code Examples" MPC5668G

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem with FlexCAN sample program from "Ver 1.0 of Code Examples" MPC5668G

Jump to solution
1,311 Views
pierreschmidt
Contributor III

Hello,

I am experiencing problems with the FlexCAN sample program found in the "Ver 1.0 of Code Examples" package (AN4241). This program transmits a singleCAN frame through CANA, the frame is received through CANC. I have a CAN probe connected to SUBD D9 (FlexCAN A) to monitor outgoing frames directly on the CAN bus. For, let's say 25% of the transmitted frames I see errors in the data stream : instead of receiving "Hello" I see unexpected data under the Code Warrior NEXXUS DEBUG, by looking at the RxDATA array, but also on the CAN monitoring software (same erroneous data), which means the problem is in the transmission not the reception. The problem seems to happen randomly, sometimes after the fourth transmission, sometimes even on the first frame. The problem appears also in the CAN ID field. Sometiimes unexpected ID are transmitted.

What could be wrong with the sample code? Does someone experience similar problem with the FlexCAN module?

Thanks a lot.

0 Kudos
1 Solution
759 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi Pierre,

The example code in the AN4241 is almost correct. You need to do a EVB connection as it is showed in the AN4241 in Figure 6. That is connect CAN TX lines together, CAN RX lines together and connect this pair to the trasnsceiver.

The TX lines are set in open drain configuration. This is needed in such connection , but also you need an external pull-up resistor on TX line or at least set internal weak pull-ups for TX line.

Do you have it? If not then use it.

However there is also another issue with this example. There are several requirements for CPI (CAN Protocol Interface) and system clocks for correct FlexCAN module’s arbitration and matching timing. This is stated within device Reference Manual in chapter 28.4.7.5 Arbitration and Matching Timing.

In details..

- A valid CAN bit timing must be programmed

- The system clock frequency cannot be smaller than the oscillator clock frequency, i.e.,the PLL cannot be programmed to divide down the oscillator clock.

- There must be a minimum ratio of 16 between the system clock frequency and the CAN bit rate.

So the second one is not fulfilled as there is no system clock setting, so it is running from the 16MHz IRC by default.

Add a PLL setting and select it as the system clock. Then the example should work.

Attached is the modification of the main.c I did.

Hope it helps.


Regards,

Petr

View solution in original post

0 Kudos
3 Replies
760 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi Pierre,

The example code in the AN4241 is almost correct. You need to do a EVB connection as it is showed in the AN4241 in Figure 6. That is connect CAN TX lines together, CAN RX lines together and connect this pair to the trasnsceiver.

The TX lines are set in open drain configuration. This is needed in such connection , but also you need an external pull-up resistor on TX line or at least set internal weak pull-ups for TX line.

Do you have it? If not then use it.

However there is also another issue with this example. There are several requirements for CPI (CAN Protocol Interface) and system clocks for correct FlexCAN module’s arbitration and matching timing. This is stated within device Reference Manual in chapter 28.4.7.5 Arbitration and Matching Timing.

In details..

- A valid CAN bit timing must be programmed

- The system clock frequency cannot be smaller than the oscillator clock frequency, i.e.,the PLL cannot be programmed to divide down the oscillator clock.

- There must be a minimum ratio of 16 between the system clock frequency and the CAN bit rate.

So the second one is not fulfilled as there is no system clock setting, so it is running from the 16MHz IRC by default.

Add a PLL setting and select it as the system clock. Then the example should work.

Attached is the modification of the main.c I did.

Hope it helps.


Regards,

Petr

0 Kudos
759 Views
pierreschmidt
Contributor III

Hello Petr,

Thank you very much, your solution solved my problem.

I understand the need of open drain configuration as the TX lines are wired together so the outputs cannot be push pull to avoid any hardware conflict. I also configured the internal weak pullup resistor on the TX line. So the hardware configuration was ok.

But as you explained in your post, because after the reset SYSCLKSEL=00, it is the 16MHz IRC that is selected for system clock. And because CLK_SRC=0 in the CANx_CTRL, the CAN engine is clocked from the 40MHz oscillator. So the CAN engine is clocked at a higher rate than the system clock, which is not acceptable for proper module operation and is the reason for the frame error I experienced.

I have one more question: in your source file you have changed: the PROPSEG, PSEG1, and PSEG2 (they are 6, 3, 3 in the AN4241 source and you changed them to 4, 4, 4). I know the final bit time is the same = 16 and the final bit frequency remains at 500KHz. But what is the reason for those little tuninngs?

Pierre.

0 Kudos
759 Views
PetrS
NXP TechSupport
NXP TechSupport

Hello Pierre,

It was just a test, this value was calculated for transceiver propagation delay 255ns and bus length of 1 meter.

This should not be so relevant for this kind of example when communication is done between modules on the board.

If you do a communication between boards/nodes with some expected bus length, both the bus length and transceiver propagation delay should be included into a bit timing calculation.

BTW there is a app note AN1798 (http://cache.freescale.com/files/microcontrollers/doc/app_note/AN1798.pdf), which gives you a guide how to calculate timing values based on a baud rate, module clock and bus parameters.

Petr

0 Kudos