Jan 22, 2021
04:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 22, 2021
04:56 AM
Hello There,
I have a question regarding the support of CAN remote frame with a XMC4100. All the CAN controllers I have worked in the past were quite straightforward concerning the treatment of this kind of data. Whenever a frame was received (data OR remote frame), RX ISR would be triggered. And inside this interrupt handler, I would extract all data from the peripheral, including RTR bit, and send upstream to my application (CANopen in this case) to be processed. In case of a remote frame, I would assembly the answer telegram, put it into the output MO, and send it, simple like that.
But based on my tests this is not the case with this microcontroller. I have a 100% functional system handling perfectly data frames (DeviceNet was the first protocol implemented), and now I am adding support to CANopen, which requires remote frames.
In my application MO1 is configured as a TX whereas MO2 is configured as a RX, both inside CAN_NODE_0 (only one). There is no hardware filter in the MO2, every telegram is received and treatment is done by the application protocol. I was expecting a similar behaviour; RX ISR would be called upon reception of a remote frame, but it did not.
So, my questions are:
- Are my assumptions right? I mean, receiving a remote frame will not be "handled" by the RX ISR?
- If so, who is going to do it? Reading the documentation I am led to believe the TX MO is going to do it. Isn't it odd?
- Is it possible to configure the peripheral in order to have the same behaviour I have described above?
- If not, how should I do it to handle remote frames as well?
- Also, my understanding, based on the docs, is that remote frames are "received" by the TX MO (although TX ISR is not triggered in this case) and a reply is automatically done. However, in our application, this cannot be done. First, telegram must be sent upstream to the application protocol to decide what to do, and then a answer is put in the transmission queue, in the TX MO.
Looking forward to hearing from you soon,
Luciano.
I have a question regarding the support of CAN remote frame with a XMC4100. All the CAN controllers I have worked in the past were quite straightforward concerning the treatment of this kind of data. Whenever a frame was received (data OR remote frame), RX ISR would be triggered. And inside this interrupt handler, I would extract all data from the peripheral, including RTR bit, and send upstream to my application (CANopen in this case) to be processed. In case of a remote frame, I would assembly the answer telegram, put it into the output MO, and send it, simple like that.
But based on my tests this is not the case with this microcontroller. I have a 100% functional system handling perfectly data frames (DeviceNet was the first protocol implemented), and now I am adding support to CANopen, which requires remote frames.
In my application MO1 is configured as a TX whereas MO2 is configured as a RX, both inside CAN_NODE_0 (only one). There is no hardware filter in the MO2, every telegram is received and treatment is done by the application protocol. I was expecting a similar behaviour; RX ISR would be called upon reception of a remote frame, but it did not.
So, my questions are:
- Are my assumptions right? I mean, receiving a remote frame will not be "handled" by the RX ISR?
- If so, who is going to do it? Reading the documentation I am led to believe the TX MO is going to do it. Isn't it odd?
- Is it possible to configure the peripheral in order to have the same behaviour I have described above?
- If not, how should I do it to handle remote frames as well?
- Also, my understanding, based on the docs, is that remote frames are "received" by the TX MO (although TX ISR is not triggered in this case) and a reply is automatically done. However, in our application, this cannot be done. First, telegram must be sent upstream to the application protocol to decide what to do, and then a answer is put in the transmission queue, in the TX MO.
Looking forward to hearing from you soon,
Luciano.
Solved! Go to Solution.
- Tags:
- can remote frames
- IFX
1 Solution
Feb 10, 2021
02:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021
02:08 AM
Hi Luciano,
Kindly check the example code available in this link.
Also check the associated appnote regarding the Multican to understand how the remote from reception is handled in XMC.
The remote frame handling is done in hardware or software according to registers being set. In case of hardware , it sets TXRQ when it receives a remote frame. If TXEN0 and TXEN1 are set to 1, data send is triggered by hardware automatically.
The DIR bit of the message object determines whether the data can be received by the transmit object. XMC_CAN_MO_SetStatus can be used to update the MOCTR register if you are using XMClib.
Best Regards,
Vasanth
Kindly check the example code available in this link.
Also check the associated appnote regarding the Multican to understand how the remote from reception is handled in XMC.
The remote frame handling is done in hardware or software according to registers being set. In case of hardware , it sets TXRQ when it receives a remote frame. If TXEN0 and TXEN1 are set to 1, data send is triggered by hardware automatically.
The DIR bit of the message object determines whether the data can be received by the transmit object. XMC_CAN_MO_SetStatus can be used to update the MOCTR register if you are using XMClib.
Best Regards,
Vasanth
2 Replies
Feb 10, 2021
02:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021
02:08 AM
Hi Luciano,
Kindly check the example code available in this link.
Also check the associated appnote regarding the Multican to understand how the remote from reception is handled in XMC.
The remote frame handling is done in hardware or software according to registers being set. In case of hardware , it sets TXRQ when it receives a remote frame. If TXEN0 and TXEN1 are set to 1, data send is triggered by hardware automatically.
The DIR bit of the message object determines whether the data can be received by the transmit object. XMC_CAN_MO_SetStatus can be used to update the MOCTR register if you are using XMClib.
Best Regards,
Vasanth
Kindly check the example code available in this link.
Also check the associated appnote regarding the Multican to understand how the remote from reception is handled in XMC.
The remote frame handling is done in hardware or software according to registers being set. In case of hardware , it sets TXRQ when it receives a remote frame. If TXEN0 and TXEN1 are set to 1, data send is triggered by hardware automatically.
The DIR bit of the message object determines whether the data can be received by the transmit object. XMC_CAN_MO_SetStatus can be used to update the MOCTR register if you are using XMClib.
Best Regards,
Vasanth
Jun 03, 2021
08:56 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 03, 2021
08:56 PM
Hello,
I had the same issue and the following is solution I found.
For Message Object n, the following setting is to monitor received Remote Frame.
CAN_MOSTATn.DIR = 1 ; To receive Remote Frame
CAN_MOSTATn.RXEN = 1 ; ditto
CAN_MOSTATn.TXEN0 = 0 ; no automatic Data Frame transmission
CAN_MOFCRn.RMM = 1; ; Transmit Object Remote Monitoring (ID, IDE bit, DLC of matching Remote Farme are copied to transmit object n in ordr to monitor incoming Remote Frames)
In my case, Acceptance Filter Mask is zero to monitor Remote Frame of any ID.
It took a while for me to find out RMM. Without RMM set, RXPND indicates reception of new message but ID/DLC of MO were not updated.
Hope this helps.
I had the same issue and the following is solution I found.
For Message Object n, the following setting is to monitor received Remote Frame.
CAN_MOSTATn.DIR = 1 ; To receive Remote Frame
CAN_MOSTATn.RXEN = 1 ; ditto
CAN_MOSTATn.TXEN0 = 0 ; no automatic Data Frame transmission
CAN_MOFCRn.RMM = 1; ; Transmit Object Remote Monitoring (ID, IDE bit, DLC of matching Remote Farme are copied to transmit object n in ordr to monitor incoming Remote Frames)
In my case, Acceptance Filter Mask is zero to monitor Remote Frame of any ID.
It took a while for me to find out RMM. Without RMM set, RXPND indicates reception of new message but ID/DLC of MO were not updated.
Hope this helps.