Other Parts Discussed in Thread: AMIC110
尊敬的 TI 团队：
目前、我正在研究 AMIC110的 DCAN 控制器发送的 RTR 帧问题、或者对这些帧的响应问题。
在我的测试场景中、DCAN 控制器每10ms 发送两个不同的 RTR 帧。 总线上有两个其他 CAN 节点响应这些 RTR 帧。
该应用相当通用、即它只是提供了一种发送和接收任意 CAN 帧的方法。 在这种情况下、我们只使用两个消息对象：
报文对象#2被配置为接收对象、接受每个可能的 ID (即掩码未使用)。 通过 IF3使用 EDMA 读取该报文对象。
报文对象#4被配置为"RTR 发送"对象、这当然也是 DCAN 中的接收对象、但我们对其设置了 TxRqst 位。
[消息对象#3可用于传输任意(非 RTR)帧、但在这种情况下不使用]。
通常情况下、这可以正常工作。 RTR 请求按照我们希望的方式进行传输、所有响应都通过 DMA 从消息对象#2接收。
然而、在闭会期间(取决于时序)、RTR 实际上不会被传输。 当我们对新的"RTR 发送"进行编程时、如果"同时"接收到对前一个 RTR 的响应、则会发生这种情况。 在这种情况下、消息似乎被接收到消息对象#4中、DCAN 中的"RTR"处理会清除 TxRqst 位。 我们可以看到、我们编程的最后一个 RTR 发送实际上在总线上看不到、并且之前的 RTR 请求的响应帧不是通过消息对象#2接收的。
TRM 对 DCAN 处理之前触发了 RTR 的帧接收的方式没有太多评价。 我很难理解为什么"通常"、当接收到对之前 RTR 的响应时、通过消息对象#2接收、而有时、当我对消息对象#4进行编程以进行新 RTR 传输时、当响应恰好同时到达时、 此报文对象似乎优先于"catch All" RX 报文对象#2。
更多详细信息：
在" 40µs "的情况下、我可以看到 TxRqst 被短暂地设置为报文对象#4、直到帧被实际发送(1Mbps 时为~30 μ s)。 此时会触发 TX 中断、我可以看到 TxRqst 被清除、TxOk 在 ES 中被置位。 当接收到响应帧时、它立即由 IF3上的 EDMA 处理、我可以看到 RxOk 在 ES 中被置位。
在"有问题"的情况下、我可以看到 NewDat 和 TxRqst 在编程报文对象#4后保持置位。 然后在~60µs ~30µs μ s 后(每 μ s 轮询一次)、TxRqst 被清除、RxOk 被置位。 根据 CAN 分析仪的跟踪结果、唯一可以接收到的消息是重复之前的 RTR。 我可以检测这种情况、因为在特定的超时时间内没有收到对之前 RTR 的响应、并且我在那里放置了一个断点。 如果我通过 IF1读取消息对象#4、我可以看到它包含与之前 RTR 响应相对应的 ID 和数据(即总线上的最后一条消息)、而不是我刚才为新 RTR 编程的 ID。
- 为什么"对 RTR 接收的响应"有时优先于"捕获所有 RX"消息对象#2 (优先级更高、接受所有消息)？
- 是否有任何方法"只发送"RTR 请求、并且 DCAN 不会干扰响应的接收？
- 在重新编程以发送新的 RTR 之前、是否有办法确保消息对象#4不符合接收条件？
- 我已经尝试使用精确匹配掩码对消息对象#4进行编程、但 a)到目前为止没有成功、b)我不确定何时真正更新了接受逻辑。 TRM 表示需要在 MsgVal 被置位前设置掩码。 这是否意味着可以动态更改 ID？
此致、
Dominic
