Not applicable
Jan 31, 2018
04:24 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 31, 2018
04:24 PM
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.
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.
- Tags:
- IFX
7 Replies
Not applicable
Jan 31, 2018
04:58 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 31, 2018
04:58 PM
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.
Jan 31, 2018
11:29 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 31, 2018
11:29 PM
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:
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
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
Not applicable
Feb 14, 2018
06:26 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 14, 2018
06:26 PM
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.
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.
Feb 21, 2018
10:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 21, 2018
10:03 AM
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
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
Not applicable
Feb 22, 2018
08:46 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 22, 2018
08:46 AM
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.
Not applicable
Mar 05, 2018
05:43 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 05, 2018
05:43 PM
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:
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.
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)
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.
Not applicable
Mar 07, 2018
10:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 07, 2018
10:51 AM
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.
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.