CAN Repeater / Retransmitter - handling Remote Frames

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hello,

We're building a product that includes a couple of CAN ports. The functionality of the CAN ports is very simple - any packet received on one of the ports is re-transmitted out the other port. There's no packet filtering or anything like that - it's a dumb CAN repeater, or CAN switch / CAN hub (whatever terminology you prefer).

My question is: how do we handle remote frames (ie the RTR bit)? It's simple to create an address mask to accept any CAN address. But I cannot find a way to do the same for the RTR bit. In fact, from reading the reference manual section "Receive Acceptance Filtering", the 4th condition seems to say I'll need to split my receive message objects into 2 groups, and then specifically differentiate between RTR = 0 and RTR = 1 frames, handling them separately. This feels a bit ugly, so before I get into coding it, I thought I'd ask the question: is there a better way? Is there a way to receive CAN packets simply ignoring the state of the RTR bit (much as we can do when ignoring the address)? Make the RTR bit a "don't care"?

Thanks.
0 Likes
7 Replies
Not applicable
Just a clarification, in case it wasn't obvious. We're talking about a CAN equivalent of an Ethernet hub. So when a remote frame is received, we don't want to respond to it. We want to re-transmit that remote frame out the other CAN port. I hope that's clear. And the same is true of course for data frames.
0 Likes
DRubeša
Employee
Employee
First solution authored First like received
Hi frankvh2,

have you maybe considered Gateway functionality for your purpose?
Especially while this statement in the reference manual states something that suits your needs:
The gateway operates equivalent for the reception of data frames (source object is
receive object, i.e. DIR = 0) as well as for the reception of Remote Frames (source object
is transmit object).


Additionaly, you may check "Foreign Remote Requests" chapter. This extended functionality you may find interesting. Also if you want to check working example of gateway functionality with FIFO then please take a look at MULTICAN_CONFIG example.

Best regards,
Deni
0 Likes
Not applicable
I'm trying to receive these RTR packets (what Infineon calls "remote frames") into a FIFO. Another device on the CAN network is generating these packets and I need to receive them.

I don't want to respond to these remote frame packets- I simply need to receive them (then later on I'll process them and do some work based on them). So I'm trying to build a FIFO to receive these remote frames into.

Question: In register MOFCR, do I need to create a Receive FIFO or a Transmit FIFO? I ask because the way the MCAN handles remote frames, it appears remote frames need to be received into a message object (MO) which is configured with DIR = 1 (transmit). So if I build a FIFO of MOs to receive remote frames message packets, in the MOFCR register is each MO a member of a receive FIFO or a Transmit FIFO?

Thanks.
0 Likes
DRubeša
Employee
Employee
First solution authored First like received
Hi,

it should be fine with Transmit FIFO, but make sure that you don´t set the message objects of Transmit FIFO to immediate transmission once the remote frame is received.

Regards,
Deni
0 Likes
Not applicable
Thanks - that's actually what I'm coding up at the moment, so thanks for the vote of support. We'll see how it goes.
0 Likes
Not applicable
It's largely working, but there's one thing I've been fighting with for a few days, that I can't seem to get working. When I receive a remote frame, I don't seem to be able to receive its ID (address).

What I can successfully do:

  • transmit normal frames, variable lengths & variable IDs
  • receive normal frames, as above
  • transmit remote frames, variable IDs (length always zero)
  • detect that I've received remote frames, but I'm not getting their ID (address)
When transmitting remote frames, I can see, on the oscilloscope, their IDs, and I can change their IDs and watch them change on the scope.

But when I receive the remote frames (DIR = 1 to receive a remote frame, into a message object configured to receive) it largely but not completely works. In the MO I see NEWDAT being set, also I see TXRQ being set (that's unique to a remote frame reception). All good. But I don't see the MOAR register being updated with the received frame message ID (message address). I have the MOAMR register setup with a fairly wide mask, so it'll accept a variety of different IDs. However when the remote frame is received, it's not updating the MOAR register with its ID.

Note this problem does not occur receiving normal frames. It only occurs when receiving remote frames. And, to be clear, I'm not using gateway mode. I'm simply trying to receive remote frames, so that software can later process them.

I've tried a few different things. I've tried with and without receive FIFOs. I've tried the IDC bit in the MOFCR register (shouldn't have any effect, and indeed it didn't). But I don't seem to be able to receive the ID of the received remote frame.

I'd love any suggestions on what to look at next. Thanks.
0 Likes
Not applicable
Doing a search in these forums, I found a post from July 19, 2012 by someone named Oreste, who said it's not possible to receive the ID of a remote frame. That scared me. Quite a lot.

Thankfully Mike C saved the day. He discovered that bit RMM in register MOFCR can be set, which allows the CAN remote frame ID to be captured. I've tested it and it works. I'm posting that info here so hopefully others can find it.
0 Likes