MCF54418 flexCAN porblems

[changliu1]

I have 2 questions about FlexCAN on MCF54418.

There are 2 flexCAN on MCF54418 and the CAN devices can work normally.

Q1.    I must enable "Self reception" function, then  the CAN device can receive the frame sent by itself.

     When the 2 FlexCAN devices are initialized, both of them can receive the frames sent by themselves. But if only 1 of the             them is initialized, the initialized one can not receive the frames from itself.

       I wonder to konw Why ?

Q2.  There are 2 FlexCANs on a  CAN bus. The terminating resistance is 120 ohms  x 2. Between the two CAN devices, there is a digital isoltor, theprogagation delay is 60ns. The baudrate is 1MHz. fsys/2=125MHz.  PRESDIV = 4, RJW =0 ,PSEG1=7,  PSEG2 =7,PROPSEG = 7.

       The test case ： CAN_A  send only, CAN_B  receive only.    When CAN_A send  one frame, CAN_B receive a lot of same frames, and the error occurs, such as bit1error/bit0error/format error.  

       But if I set  the CANCTRL[RJW] = 3, the CAN communication becomes normal. 

      Why?

[TomE]

> But if only 1 of the them is initialized, the initialized one can not receive the frames from itself

That's normal. A device on a CAN bus can only transmit a message if there is a different device on the same CAN bus that can receive that message, check it and send back the "ACK" bit. That device does not have to have filters set up to receive that message - it only has to be enabled (and at the right baud rate and so on). In the normal case, which is in a CAR, the first device that powers up will keep repeating the first packet (without signalling an error) until the SECOND device powers up and can send the ACK.

> theprogagation delay is 60ns. The baudrate is 1MHz. fsys/2=125MHz.

> PRESDIV = 4, RJW =0 ,PSEG1=7,  PSEG2 =7,PROPSEG = 7.

So that's 125 MHz / 5 / 25. Good. that's exactly 1MHz.

If you are setting up a CAN bus you have to do all of the arithmetic to prove that the design is correct. You can't just plug things together and pick a baud-rate like you can with RS-232. CAN isn't like that.

Freescale (now NXP) has a good App Note on this topic. Search for and read AN1798.

Quickly analysing your delays, your Quanta are 25MHz or 40ns. PROPSEG is "7" so the value is "8". So your system is set up for an absolute maximum propagation delay of 8*40 or 320ns. That's the delay from the transmitter, out through its transceiver, then through any EMC-related hardware that you may have (capacitors slowing the signal down), then through that delay-thing, then through the Receiver's transceiver and into the receiver. Then the Ack has to travel in the reverse path back to the Transmitter, so double it. Is that less than 320ns worst case?

> But if I set  the CANCTRL[RJW] = 3, the CAN communication becomes normal.    Why?

Read AN1798.

Why did you choose "1" in the first place? There are special cases related to signal noise patterns and clocking where you might want to set SJW that low. It is more normal to set it "as high as you can", which is to set it to "3" unless PSEG1 or PSEG2 are less than 3, in which case SJW has to be limited to those values.

And then after doing all the maths, you should always connect an oscilloscope to the CAN bus and make sure the signals look like you expect them to, with the delays you expect. I had an interesting case where someone on another forum posted a picture of some very droopy CAN signals and their schematic and I was able to say "if those capacitors that are meant to be 330pF are actually 330nF then that will explain your problems" which turned out to be the case.

And if it isn't working (Antonio) then that's the FIRST thing you should do.

Tom

[antonioagenjo]

Thanks, Tom for your detailed explanation.

I had already read NXP AN1798 application note. It is what I used to choose the registers configuration values. I am pretty sure that propagation delay is not the problem, as both bus length is just a few cm. I also had checked the signals with the oscilloscope, and they look pretty good. I have the two processors running, and they are able to send ACK’s. In fact, communication works at 500 kbps, so acknowledgment works. It is when I configure both processors to run at 1 Mbps bus speed that some messages are lost. If I connect the CAN-USB interface in read-only mode, I can see an unexpected high message rate (due to retrys, I guess), but if I connect it in Tx/Rx mode, message rate becomes normal (the one I programmed) and no message is lost.

I might be missing something, but I can’t figure out what it is. Can you guess any reason why the FlexCAN might not be transmitting ACK’s at 1 Mbps, but transmits them at 500 Mbps?

Thank you.

Antonio AGENJO SANDONÍS

Software Architect

AR Software – TEAMA-TL4

Airbus Defence and Space

T +34 (0)9 14 43 10 54

E antonio.agenjo@airbus.com<mailto:antonio.agenjo@airbus.com>

Airbus Defence and Space, S.A.U.

Pº John Lennon, 2

28906 Getafe (Madrid)

España

PAntes de imprimir, piensa en el MEDIO AMBIENTE / Before print, think about ENVIRONMENTAL

De: TomE

Enviado el: miércoles, 20 de septiembre de 2017 9:00

Para: Agenjo Sandonis, Antonio

Asunto: Re: - Re: MCF54418 flexCAN porblems

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: MCF54418 flexCAN porblems

reply from Tom Evans<https://community.nxp.com/people/TomE?et=watches.email.thread> in ColdFire/68K Microcontrollers and Processors - View the full discussion<https://community.nxp.com/message/944714?commentID=944714&et=watches.email.thread#comment-944714>

[TomE]

> If I connect the CAN-USB interface in read-only mode, I can see an unexpected high

> message rate (due to retrys, I guess), but if I connect it in Tx/Rx mode, message

> rate becomes normal (the one I programmed) and no message is lost.

That means that the "CAN-USB" thing in "Tx/Rx" mode is providing the ACKs. When it is in R/O mode it doesn't. That means the system is relying on the other device to send the ACKs. What you're seeing means it isn't doing that. So there's something wrong with the programming, the clock rates or the signals on the bus.

The "digital isolator" may be the problem. Take it out and see if the problems go away. It may not work properly at 1MHz.

When you have the "CAN-USB" thing on one side of the isolator, then it may allow the FlexCAN device on the same side to work properly (as it is providing the ACKs locally).

Check the signals on BOTH SIDES of the isolator at 500 and 1000. Look for differences.

The "digital isolator" has to act as a two-way switch. It has to "know" which way it is driving a signal (left to right, or right to left, or both), and this is tricky. It may not be able to do this properly at 1MHz.

A simpler way to have "isolated CAN" is to use an isolated CAN Transceiver. That can do the work far more simply without having to act as a "switch". Or you put the isolator between the transceiver and the micro, like this:

https://www.nve.com/newsletter/nve_newsletter--3-10.htm

https://www.nxp.com/docs/en/data-sheet/TJA1052I.pdf

You're also saying "messages are lost" without saying where they're lost. It is possible that the hardware is working properly, but your software can't handle the message rate at 1MHz, but can handle it at half that rate. I don't think that's what you mean though.

Tom

[antonioagenjo]

Hello, changliu

I have a similar issue with FlexCAN on the MCF54418.   I have a similar architecture (2 processors on the same bus) and I am configuring my FlexCAN with the same values as you (1 Mbps, fsys/2=125MHz.  PRESDIV = 4, RJW =3 ,PSEG1=7,  PSEG2 =7,PROPSEG = 7) but I can't get it to work properly.  Even though I configured RJW = 3, I have the same behaviour that you see when you configure RJW=0 (lots of retries from the sender).

I might be missing something in FlexCAN configuration, but don't know exactly what it is.  Furthermore, I can configure FlexCAN to work properly at 500 kbps, so I might not be far of making it work at 1 Mbps.

I suppose that your issue with RJW might be related to acknowledge bit...  It seems the transmitter is not receiving the ACK bit from the receiver, and that might be why the transmitter keeps on retrying to send the same message over and over.

Any help would be really apreciated.  Thank you.