[参考译文] CC2745P10-Q1：通道同步问题和 iCall_abort 问题

您好、赵先生、  

问题 1：  

您是否在使用 SDK 中的 Python 演示或团队开发的嵌入式演示？ 如何提取 RSSI 数据？ 这应该通过 BLEAPPUTIL_EVT_CM_REPORT_EVENT_CB 完成。 该事件从回调触发。 发送的数据将来自 cmReportEvt_t 结构。 如果这是您正在做的事情、请告诉我。  

启动 CM 多长时间后、才能收到 CM_TRACKING_STOP_EVT？ 此外、此处的监控超时意味着什么？  

问题 1 发生的频率如何？ 每次启动 CM 时都会发生这种情况吗？  

问题二：  

您是收到来自 CM_UpdateConn 函数的状态还是错误代码？ 此错误发生的频率如何？  

请告诉我。  

谢谢、
Isaac

您好、Isaac、

很抱歉,由于公共假日的延迟回复.

我们会将 TI 嵌入式演示集成到我们的项目中。

监控超时是使用  CM_TRACKING_STOP_EVT 进行回调报告的停止原因：

这两个问题都发生的可能性很高。

您好、赵先生、  

同样、您能告诉我是使用自定义嵌入式示例、还是使用 SDK 中的 Python 演示吗？  

CM_MONITORY_TIMEOUT 停止原因指示 CM 在超时到期之前无法跟踪连接。  

发生这种情况的原因有两个。  

如果连接没有开始跟踪、您的 timeDeltaInU 很可能不正确。 您需要通过确定将连接数据从 CMS 节点传输到 CMR 节点所花费的平均时间来计算该值。 如果此值不正确、则 CMR 将无法找到要开始的连接。 此外、timeDeltaMaxErrInU 对于估算数据传输的最大误差非常重要。 要计算此值、您应使用平均时间 DeltaInU（在 10-20 次测试之后）、然后计算 10-20 次测试测量与平均测量之间误差的平均值。  

第二种情况是连接执行连接参数更新、且连接监视器未针对新的连接参数正确更新。 CMR 端必须使用 CM_UpdateConn 函数更新连接参数。 更新连接参数必须从 CMS 节点发送。 再次、timeDeltaInU 和 timeDeltaMaxErrInU 在此发挥作用。 当连接参数更新发生时、CMS 回调将发送一个与更新的参数相关的事件。 事件处理程序可以截获 BLEAPPUTIL_CM_CONN_UPDATE_EVENT_CODE。 发生这种情况时、BLEAppUtil_cmConnUpdateEvt_struct 将包含特定的更新事件、根据该事件、您可以发送包含这些参数更改的结构。 包含特定参数更新更改的结构体位于 cmConnUpdateEvt_t 结构体中。 然后您需要将数据发送到 CMS 节点。  

如果此说明不起作用、请发送问题的逻辑跟踪。 您可以 在此处找到更多相关信息。  

如果您有任何问题、请告诉我。  

谢谢、
Isaac

您好、Isaac、

感谢您的答复。 我们正在检查  timeDeltaInU 和 timeDeltaMaxErrInU  的配置。

我们正在研究 TI 嵌入式示例。  

关于 第二个问题、您是否有任何想法可以帮助我们继续调查？

谢谢。  

Chao、  

请执行第二段中的信息。 这将有助于监督超时。 如果这不起作用、我们可以进一步讨论、我可以进一步调试。 这些信息是正确设置连接参数更新所需的信息。 我相信问题是由此而产生的。  

谢谢、

Isaac

Isaac

我没有得到你的观点,  

当我说第二个问题,它是  

问题二：

问题发生在我们调用连接 Monitor_Update 连接后,我们可以观察:
将陷阱编程到 iCall_abort 中。
调用栈如下所示：CM_UpdateConn()->BLE_invokeIfRequired()->iCall_directAPIva()->iCall_abort()
调试后,我们发现 iCall_directAPIva 函数将收到 ICALL_errno_timeout 错误。

您好、赵先生、  

我正在研究第二个问题。 我只是想让您检查一下、按照我之前回答中的说明是否可以解决问题。  

谢谢、

Isaac

你好、 Isaac、  

 调整参数后  timeDeltaInU  至 30~40。我们测试并提高了成功率。但仍然存在 监督超时问题。

您是否在问题 2 上有任何进展？ 问题 2 仍然存在。

谢谢。

您好、赵先生、  

我很抱歉、我正在努力重现这个问题。 到目前为止、我还没有多少运气。 您能否提供要更新到的连接参数？  

我将在下周通过星期五做出更多回应 (11/7)。  

谢谢、
Isaac

您好、Isaac、

这里是我们的屏幕截图。

您是否有关于此问题的任何信息。

Chao、  

1.收到监视超时时时时、连接是否仍处于活动状态？  

2.通过 PA/LNA 引脚,您是否观察到 CMR 在尝试启动时缺少初始连接事件数据包? 如果是、则这很可能表示您的时间增量仍处于关闭状态。  

3.请给我发送 CMS 和 CMR PA/LNA 的逻辑跟踪。  

4.调用 CM_UpdateConn 时是否有错误代码？ 该功能是否正常执行？  

5.你提到你不相信频道是同步的。 你为什么这么认为? 是否正确地将连接数据发送到 CMR（并解析）？  

请提供此反馈的答案。  

谢谢、
Isaac

回答您的项目 4：

问题发生在我们调用连接 Monitor_Update 连接后,我们可以观察:
将陷阱编程到 iCall_abort 中。
调用栈如下所示：CM_UpdateConn()->BLE_invokeIfRequired()->iCall_directAPIva()->iCall_abort()
调试后,我们发现 iCall_directAPIva 函数将收到 ICALL_errno_timeout 错误。

谢谢。

Chao、  

但 CM_UpdateConn 返回成功吗？ 这就是我所说的返回误差。 我理解您看到了 ICAL_errno_timeout、但我尝试确定 CM_UpdateConn 是否失败、然后您看到它。  

此外、请回答其他问题。  

谢谢、

Isaac

你好 Issac

调用堆栈显示：

CM_UpdateConn()->BLE_invokeIfRequired()->iCall_directAPIva()->iCall_abort()

它将卡在函数 iCall_ABORT 中。 无法返回。