ColdFire/68K Microcontrollers and ProcessorsのトピックFlexcan - Receiving RTR requests

Flexcan - Receiving RTR requests

Ahlan — Wed, 05 Feb 2014 17:13:58 GMT

Hi,

Is there any way using MCF5235 Flexcan that I can read all the CAN messages on the CAN bus including remote transmission requests?

When I setup Rx buffer 15 mask to all don't care I receive all the messages except RTR messages.

Page 21-29 of the MCF5235 RM says that "A received remote frame is not stored in a receive buffer. It is only used to trigger automatic transmission of a frame in response"

However I don't want to react to the RTR I merely what to monitor *all* the CAN bus traffic.

Has anyone any ideas how I might do that?

Best wishes,

Ahlan

Re: Flexcan - Receiving RTR requests

TomE — Thu, 06 Feb 2014 05:36:12 GMT

Have you tried "Listen Only Mode"? That might do it, but note it won't ACK any messages so you'd need at least two other devices on the CAN bus.

Tom

Re: Flexcan - Receiving RTR requests

Ahlan — Thu, 06 Feb 2014 10:05:58 GMT

Hi,

I thought about that but how would I know that the message was an RTR?

There doesn't seem to be anything that indicates that a message received into a buffer was a RTR.

Ahlan

Re: Flexcan - Receiving RTR requests

TomE — Fri, 07 Feb 2014 01:13:15 GMT

You're right. It looks like that controller can't be used as a "CAN Monitor". If you need to do that you'll have to buy a real one or use a different controller.

It can't even receive messages that aren't ACKed by other devices, so it couldn't see a single device trying to transmit.

The "Listen Mode" is very poorly documented. The chip may be more capable than the User Manual says it is. I'd try to reverse-engineer it and see if it can receive these messages at all, and if it leaves a "hint" anywhere. There are some Reserved bits in the message buffer, and it might set the RTR bit on receive.

Your system should probably allocate message IDs so it only ever sends the RTR bits on unique IDs anyway.

You should also search this forum for "RTR" if you haven't done so already. I've just done that and found a previous post from you in August where you had problems with "loose RTR frames" (you were losing them :-). How did that end up? Did you submit a Technical Request?

https://community.freescale.com/message/355862#355862

Tom

Re: Flexcan - Receiving RTR requests

Ahlan — Mon, 10 Feb 2014 14:03:32 GMT

You have confirmed what we believed - It's nice to have a second opinion. ;-)

We had hoped to use the FlexCan as a CAN monitor but we will probably now use a different CAN controller and processor.

Probably FM3 - although we have absolutely no experience of this - so that should be fun ;-)

The technical request went nowhere.

So we simply modified the protocol to retry if the RTR did not solicit the expected response.

Not ideal but an acceptable solution for our application.

Ahlan

Re: Re: Flexcan - Receiving RTR requests

TomE — Mon, 10 Feb 2014 23:33:06 GMT

Freescale makes two different types of CAN controllers, generally called FlexCAN and MSCAN.

The MSCAN part is available in some of the other Freescale parts. If you want to stick with ColdFire, you can use the MCF51JM128.

Checking the Reference Manual, the MSCAN part looks like it does store the RTR bit in the receive frame, so you can use it to monitor these packets.

The following sentence indicates it does NOT support "RTR response in hardware":

Table 11-28. IDR3 Register Field Descriptions — Extended

Remote Transmission Request — This flag reflects the status of the remote transmission request bit in the CAN

frame. In the case of a receive buffer, it indicates the status of the received frame and supports the transmission

of an answering frame in software.

That does mean it would solve your "missing RTR response" problem.

You could add a CAN controller to an SPI port. I've developed a product based on the MCF5329 with three external SPI-connected CAN controllers, (total of 4 CAN ports), but with that experience I'd strongly recommend against doing it that way. Programming CAN parts is hard enough without putting them on the end of an SPI bus.

Tom