AT90CAN and RTRTAG bit

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the code which uses rtrtag bit. What I have found tonight is that if I have more than one device responding simultaneously with auto reply messages, them do not come through.... Yes, it should have arbitration, and those messages have different idts and work fine without rtr, but seems not to work with it. Did someone else see this phenomenon?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Start with the data sheet section 19.5.1 Operating Modes page 242 19-1. MOb Configuration. This table tells you the settings for the CANCDMOB register CONMOB1/CONMOB1 MOb bits configuration, RPLV reply valid bit and the CANIDT4 register RTRTAG bit.

You should start with only one auto reply remote frame. You can try multiple remote frames after you get one remote frame working correctly. I have tried to make this more than a simple follow the instructions type of reply by exploring some of the interactions.

Always initialize the CANPAGE MOBNB3, MOBNB2, MOBNB1 and MOBNB0 bits first thing to point at the MOb you want to use.

Be careful about how you set the CANIDM4 register RTRMSK for the MOb. Make sure the MOb RTRMSK is always a one.

The MOb RTRTAG is what changes a normal Tx Data frame into a Tx Remote Frame. It is also what changes a normal Rx Data Frame into a Rx Remote Frame. If you clear the MOb RTRMSK bit then it will allow a normal Rx Data Frame to receive the Tx Remote Frame trigger, but a Rx Data Frame does not do an auto reply like the Rx Remote Frame.

Obviously, first you need to setup all the Rx Remote Frame MOBs. These should have RTRTAG, RTRMSK and RPLV set. The CANMSG data bytes (up to eight total) should be initialized along with the DLC3, DLC2, DLC1 and DLC0 bits for however many CANMSG bytes you initialized. All four CANIDT registers need the IDT setup and the CANIDM registers IDMSK bits should be setup. The rest of the things that need to be taken care of are in section 19.5.1.3 Rx Data & Remote Frame. After the auto reply MOb is matched, the RTRTAG and RPLV bits will be cleared before the auto reply Tx Data Frame is sent. You can check for these bit values as a diagnostic too see if the auto reply was recognized or not.

If you set the IDMSK bits to allow a range of IDTs to match, after the Rx Remote Frame the CANIDT bytes will be updated with the actual received IDT value from that range of possible values (19.5.1.3 Rx Data & Remote Frame number 4). It will also update the IDE type (11 bit or 29 bit) if you set the IDEMSK bit to zero. In any case you do not want to try setting up universal 11 bit IDT and 29 bit IDT receives yet, so make sure the MOb IDEMSK bit is set to a one.

Now you need another type of MOb for Rx Data Frame already setup and waiting. The Rx Data Frame matches the IDT of the Tx Remote Data Frame, but since its RTRTAG is cleared it ignored the Tx Remote Frame. However, when the other MOb Rx Remote Frame does receive the Tx Remote Frame it will send the Tx Data Frame that this final Rx Data Frame MOb receives.

After the Rx Remote Frame and Rx Data Frame is setup and waiting to go, now you initialize and send the Tx Remote Frame. Again, the MOb RTRTAG is set. See section 19.5.1.2 Tx Data & Remote Frame for the rest of the details.

Always remember to only set the MOb CANCDMOB register CONMOB1/CONMOB1 MOb bits as the very last thing for any MOb setup. As soon as these bits are set the MOb will be activated and executed by the CAN hardware.

For testing and getting one to work, I recommend setting all the CANIDM registers IDMSK bits to a one. Check the data sheet as some bits in the CANIDM register are reserved and always supposed to be set to zero.

The short description is the Tx Remote Frame goes out with its RTRTAG set. This means it can only match a Rx Remote Frame with the exact same IDT and with its RTRTAG set (assuming you follow the CANIDM recommendations). If that Rx Remote Frame has its RPLV bit set and some DLC number of CANMSG bytes ready to go, it will automatically switch to a Tx Data Frame (as per table 19-1. MOb Configuration) and Tx the CANMSG bytes with the same IDT, except the RTRTAG bit is now cleared to zero.

Also keep in mind that any AT90CAN128 MOb Rx of any kind will not receive any MOb Tx of any kind if both Rx and Tx are on the same physical CAN node (i.e. the same AT90CAN128 chip). You can do it with only two CAN nodes, but you have to arrange it so the Rx and Tx MObs are always different physical nodes.

So, you setup:
Rx Remote Frame MOb in one node
Rx Data Frame MOb in another node
Tx Remote Frame MOb (it can be in the same node as the Rx Data Frame, but not the same node as the Rx Remote Frame)

The Tx Remote Frame triggers the Rx Remote Frame which initiates an auto reply Tx Data Frame that is finally received by the Rx Data Frame.

After you get this single auto reply working, then you can expand to multiple auto reply MOBs. If you have taken care of all the initialization requirements correctly they shouldn't interfere with each other.

I have not tried messing with the mask to make a single MOb Tx Remote Frame trigger multiple Rx Remote Frame MOBs, using the mask in each Rx Remote Frame MOb (each MOb with a unique IDT) to force a match to the single Tx Remote Frame IDT. The problem I see is the Rx Remote Frame MOBs will all replace their IDT values (19.5.1.3 Rx Data & Remote Frame number 4 also 19.5.1.4 Automatic Reply number 2) with the single Tx Remote Frame IDT value. Then all the auto replies sent from each Tx Data Frame MOb would all have identical IDTs no matter what you had initialized them to. Since they all would have the same IDT and all the ones on different nodes would all start at the same time, I cannot say exactly what would happen. I would expect the possibility of errors since there will not be any bitwise collisions until way down in the Tx Frame bits in the CANMSG bytes (I'm not sure how deep the CAN arbitration goes into the CAN frame).

So my question would be, how do you get more than one device to simultaneously respond with an auto reply and have unique IDT values in the auto reply Tx Data Frames? If a single Tx Remote Frame triggered all the simultaneous auto reply Tx Data Frames, they would all have the exact same IDT as that single Tx Remote Frame.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike, I do appreciate your reply. But let me explain again what kind of problems I do and do NOT have. I do NOT have any problem to receive auto reply from any one node/device. The problem starts when one request triggers multiple nodes/devices to respond. Once again I can and do get auto reply from ANY single node/device. At the moment when the SAME request triggers more than one node/device to auto reply I suspect that arbitrate fails. Auto reply does not come through. Auto replys from the different devices have different IDT fields, so it is legitimate from arbitrate stand point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, you missed my point. Your original description:

brberie wrote:
....I have more than one device responding simultaneously with auto reply messages,....and those messages have different idts....
You cannot send a single Tx Remote Frame to multiple Rx Remote Frames and maintain different IDTs. When any Rx Remote Frame on any device receives the Tx Remote Frame, the first thing it does is write the IDT from the Tx Remote Frame into the Rx Remote Frame IDT field. When the auto reply happens and sends a Tx Data Frame it now has the exact same IDT as the original Tx Remote Frame.

See the data sheet page 244 section 19.5.1.4 Automatic Reply number 2

data sheet wrote:
The IDT, the IDE, the other tags and the DLC of the received remote frame are used for the reply.
This is telling you all the Rx Remote Frames overwrite the IDT that you set and replaces your setting with the received Tx Remote Frame IDT setting.

This is a basic function of the MOb acceptance hardware as show in figure 19-10 on page 245. It is also described in section 19.5.1.3 Rx Data & Remote Frame number 4

data sheet wrote:
On a hit, the IDT, the IDE and the DLC of the matched MOb are updated from the incoming (frame) values.
Updated means the same thing as the Rx Remote Frame IDT value you set was overwritten and destroyed.

So, a single Tx Remote Frame sent to trigger multiple Rx Remote Frames will always force all of the multiple responses to have the exact same IDT. Whatever IDT you set was wiped out and replaced as soon as that first Tx Remote Frame was received and accepted by each MOb acceptance hardware.

You said

brberie wrote:
....those messages have different idts and work fine without rtr....
I didn't see anything about any RTR working in your original post. How can you explain “again” what you didn't explain the first time. If you want more focused replies please be more specific. I covered the basics in my original reply because I do not know exactly what is going on in your end, aside from the briefest description. This gets fairly complex and I wanted a basis for a common understanding. My first reply covered exactly the stuff I would review in my own CAN project development if I was having trouble with RTRTAG remote frames. However, ultimately your problem appears to be you are trying to do something impossible (at least from your description). If you want multiple responses with different IDTs, then you you cannot use the RTRTAG auto reply (RPLV). You will have to use software in each different CAN node to send each unique IDT response. You could assign a special IDT value for a normal Tx Data Frame (not Remote Frame) to trigger the software response in each CAN node.

As an afterthought, you said

brberie wrote:
Auto reply does not come through.
Are you processing all the CANSTMOB and CANGIT register error values? If not, you may not realize the auto reply did come through, but failed with an error instead of a normal completion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you!

Quote:
See the data sheet page 244 section 19.5.1.4
That is what I've missed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did miss one point that I just thought of. You can only really use one Rx Remote Frame MOb with the same IDT in each AT90CAN128 at any one time. The MOb acceptance filter will always find the first matching MOb, starting from the lowest numbered MOb (0 through 14) and only use that first MOb with the IDT match. Any other Rx Remote Frame MObs in that same AT90CAN128 with a matching IDT will be ignored (they can be used for the next Remote Frame). I have not actually tried this to verify it, but this is my understanding of how the MOb acceptance hardware works.

For simplicity I left out that all the above IDT matches also involve the IDMSK registers.

This does not address your problem, I'm just adding it to the record.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the key phrase is

Quote:
The IDT, the IDE, the other tags and the DLC of the received remote frame are used for the reply.
In other words arbitration can not work. The only question remains is why there are no any error flags/conditions what so ever...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you called that section 19.5.1.4 key phrase is based on the way the MOb acceptance filter works. The other section 19.5.1.3 information is the same thing. I do not understand your interpretation:

brberie wrote:
In other words arbitration can not work.
The arbitration is covered in 19.2.1 Principles:
data sheet wrote:
Bus access conflicts are resolved by bit-wise arbitration on the identifiers involved by each node observing the bus level bit for bit.
Section 19.2.2.1 Can Standard Frame:
data sheet wrote:
... the "Arbitration field" which consist of the identifier and the "Remote Transmission Request (RTR)" bit used to distinguish between the data frame and the data request frame called remote frame.
Figure 19-1. CAN Standard Frames has a drawing of the arbitration bits. What you were probably doing is sending out multiple simultaneous responses with exactly the same IDT which all passed arbitration because there were no bitwise differences in the arbitration field bits. However, if there is any difference in any of the CANMSG data bits, you would have collisions outside the arbitration field that would probably result in active error responses.

Also keep in mind that if you have any waiting Rx Data Frames based on the IDT that got destroyed, the auto reply will never send that IDT and the waiting Rx Data Frame with that different IDT will never receive anything because it was never sent in the first place. These will not have any errors, they just will never get anything. The only single IDT that will be sent is the one from the original Tx Remote Frame.

If a data collision outside the arbitration field does cause any errors and you have no matching IDT MOb in the CAN node, then the error will go into the general CANGIT register (if it sets any error bits at all). There always has to be a MOb with a matching IDT in order for the error to go into the CANSTMOB register for that MOb.

Remember that active error responses are not the same thing as the error flags in CANSTMOB and CANGIT. Active error responses may just increment the CANTEC and CANREC error counters if retries are attempted (I'm not sure how the CANSTMOB and CANGIT would work in this case). The eventual result may be a BOFFI Bus Off interrupt if enough Tx retry attempts fail.

I think the arbitration probably is working just like its supposed to. You are messing with it by sending multiple simultaneous identical IDT frame bits which all pass arbitration together. You need to look in CANSTMOB, CANGIT , CANTEC, CANREC and BOFFI to see what is actually happening within any AT90CAN128 node under these conditions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because

Quote:
the IDT, the IDE, the other tags and the DLC of the received remote frame are used for the reply
if someone(not me anymore)sets up several nodes to auto reply, the arbitration fields are going to be the same for all those nodes which obviously kills any possibility of the arbitration between them. That is what I meant saying arbitration can not work.

I have. There is no any indication of any error...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If all of the simultaneous auto reply frames with the single IDT sent exactly the same CANMSG data, there wouldn't be any bit collisions or errors. All the Rx Data Frame MObs that match the IDT would get what they think is a single reply data frame and finish with an Rx OK. As long as all the CAN bus dominate bits match exactly, no CAN transmitter tell how many nodes are actually sending data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Data segment is not the same. Can sniffer does not sense any valid can message.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does the CAN sniffer have to do with anything?

You already said single RTRTAG auto replies work and you already know you are misusing the AT90CAN128 CAN by trying to get simultaneous auto replies which all have the same IDT from different nodes. A CAN sniffer will not tell you anything about what is actually going on inside the misused CAN nodes.

Have you checked the the AT90CAN128 RTRTAG and RPLV bits in the Rx Remote Frame MObs? These will be set to zero if the auto reply has been triggered. If they are still set to one after you think the auto reply should have gone out then something else went wrong and the node failed to recognize any matching IDT Tx Remote Frame and trigger the auto reply.

Have you checked all the CANSTMOB, CANGIT, CANTEC, CANREC and BOFFI bits and values after each CAN frame (or with interrupts)?

An external CAN sniffer cannot tell you squat about the internal state of any AT90CAN128 CAN nodes. Since you know you are going out of bounds and misusing the nodes, the AT90CAN128 CAN internal state registers are the only ones that will have useful information.

Again, my advice is you cannot use the RTRTAG auto reply this way.

1) You should to do your own software driven unique IDT multiple replies without using the RTRTAG auto reply hardware. If the software in each AT90CAN128 is the same (i.e. same execution delay) you might still get some simultaneous auto replies with different IDTs on the CAN bus.

2) or send a separate RTRTAG Tx Remote Frame for each unique IDT that you want an auto reply from (only one Rx Remote Frame exists for any IDT on the CAN network), which you already have working. This uses single RTRTAG auto replies one after another and will never be simultaneous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike B wrote:
What does the CAN sniffer have to do with anything?

brberie wrote:
Can sniffer does not sense any valid can message.

It means that it may and most likely there is some activity on the physical layer, but nothing valid
Mike B wrote:
Have you checked the the AT90CAN128 RTRTAG and RPLV bits in the Rx Remote Frame MObs?
Have you checked all the CANSTMOB, CANGIT, CANTEC, CANREC and BOFFI bits and values after each CAN frame (or with interrupts)?

brberie wrote:
I have. There is no any indication of any error....
As well as no changes in the Rx Remote Frame MOb,
Mike B wrote:
Again, my advice is you cannot use the RTRTAG auto reply this way.

brberie wrote:
if someone(not me anymore)sets up several nodes to auto reply
On the single request.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

brberie wrote:
It means that it may and most likely there is some activity on the physical layer, but nothing valid
Does your CAN sniffer detect and report active error frames? These are described in the BOSCH specification. They allow a CAN node to signal all other CAN nodes that an error occurred and to ignore the current frame.

brberie wrote:
As well as no changes in the Rx Remote Frame Mob,
This tells you the Rx Remote Frame MOb didn't recognize a valid Tx Remote Frame with any matching IDT. The Rx Remote Frame is still waiting to send the auto reply. Did the other node that sent the trigger Tx Remote Frame complete with a MOb Tx OK? Did you see any Tx Remote Frame on the CAN bus with the sniffer? If the Tx Remote Frame never went out then your CAN Tx node has a problem. If the Tx Remote Frame went out, then its a problem with your CAN Rx node (wiring, setup, etc.). Since the RTRTAG auto reply response never triggered, you are not at the level of sending any reply yet. If no reply is sent, there is noting to arbitrate and there are no errors generated by doing nothing.

Since no auto replies with matching IDTs have been sent yet, none of the arbitration stuff has had a chance to work yet, which is why you have not seen any errors. If you really do get multiple CAN Tx Data Frames with the same IDT to simultaneously send, I think the arbitration will fail to detect this and since the CANMSG data is different it will cause an active error frame on the CAN bus when a dominate CANMSG bit collides with a recessive CANMSG data bit. This should at least increment the CANREC and CANTEC error counters and cause an automatic retry. However, you can't see it until it happens. This is where knowing the internal state of the CAN nodes is critical.

brberie wrote:
On the single request.
You can do a single request if you do not use RTRTAG, write the software for each CAN node to receive a normal CAN Rx Data Frame, recognize it as a request for additional data (the Tx Data Frame IDT value itself may be enough information if its selected to have this special meaning) and then send that requested data with a normal CAN Tx Data Frame. All the nodes with this software would respond with different IDT Tx Data Frames to a single request. This software is more of an application level than driver level code.

Forget about using RTRTAG unless you want data from only one single CAN node with only one unique IDT.

brberie wrote:
if someone(not me anymore)sets up several nodes to auto reply
Its up to the CAN network designer to determine what IDT values are used for by whatever nodes. If other people are going to mess with this they have to follow the designer's rules or problems will occur. You need to make sure “someone else” knows your design rules. The designer could make decisions like not allowing any RTRTAG auto replies to be used at all (just always have the driver clear the RTRTAG and RPLV bits). Just because the hardware is there it does not mean you have to use it all. This would force all replies to be handled at the application software level and “someone else” would never be able to mess up with bad RTRTAG auto replies. Without a CAN design or rules to follow, “someone else” needs to keep their hands off!