你好对话框，
我们正在看到一些奇怪的行为，其中一些包含DA14581芯片的系统。在我们的系统中，DA14581是从设备，不同的供应商提供主芯片芯片。
在少数这样的系统上，我们观察到从DA14581的空的PDU传输中随机暂停。连接了BLE包嗅探器迹线。随机丢失在轨迹中可见，作为吞吐量的液滴。每个暂停始终始终为1.1 - 1.2秒。在跟踪时没有交换应用层流量 - 这些都是空闲数据包。
我们的系统应该相同构建和配置。在跟踪时运行的应用程序通过IDE下载（不耗尽OTP）此行为仅在少数此类系统中展出。从等待时间设置为0（多次确认！）。
你觉得这种行为背后的原因是什么?在这些情况下，它会导致连接下降。
谢谢,
吉姆
附件：
设备:
嗨jameshiebert，
那么，这种行为是在共享相同构建和fw的设备上随机表现出来的?是这样吗?表现出这种行为的设备是独特的，我的意思是，你是否在类似的环境中在多个设备上执行了这个测试，而在连续的测试中只有一个(例如)设备暴露了这种行为?还有大师的联系呢?这个行为是否与一个特定的主服务器相关，或者无论链接的主服务器是什么都会发生?
你有实际的嗅探跟踪分享事件发生时和你确认这个副作用是由于错过了从581年的事件,所以在嗅探器日志你看数据包从主,没有包从奴隶?您已经附加了吞吐量的图表，但这对查找根本原因没有太大帮助，当问题发生时的当前捕获也会有帮助，并通过功耗实际看到581个未连接事件。它也会帮助提到SDK，你正在使用和设备的配置，是应用程序完全运行在581上或你正在使用HCI接口，我假设应用程序完全运行在581上。你的低功耗时钟怎么样，你是用rcx还是xtal？
谢谢mt_dialog.
嗨对话框，
那么，这种行为是在共享相同构建和fw的设备上随机表现出来的?是这样吗?[是的。具有完全相同的HW和FW配置的少数（少量百分比）展示了丢失行为。]
表现出这种行为的设备是独特的，我的意思是，你是否在类似的环境中在多个设备上执行了这个测试，而在连续的测试中只有一个(例如)设备暴露了这种行为?[正确的。在一个特定的环境中，有一个具有十几个或如此相同的测试站的实验室，所有具有具有从581芯片的DUT，并且只有一个DA14581表现出行为。我们将电路板与不同的板（不同581）交换，问题消失了。它也发生在其他环境中。该行为遵循581（或至少焊接的电路板）。]
还有大师的联系呢?这个行为是否与一个特定的主服务器相关，或者无论链接的主服务器是什么都会发生?[绝大多数主设备是相同的自定义内置框。有一些异常值 - 商业智能手机。我将用一个已知的“失败”DA14581和智能手机进行实验。]
当事件发生时，你有真正的嗅探器踪迹可以分享吗?[我附加了一个有2个辍学者的跟踪。我们使用Teledyne LeCroy ComProbe协议分析系统。你能看懂那些文件吗?]
．..您是否验证了这种副作用是由于581侧的遗漏事件造成的，因此在嗅探日志中您看到了来自主端的包，而没有来自从端的包?这也是正确的。master继续发送空闲数据包，DA14581没有响应。这些间隔是随机发生的，但总是持续大约1.1 - 1.2秒。
您已经附加了吞吐量的图表，但这对查找根本原因没有太大帮助，当问题发生时的当前捕获也会有帮助，并通过功耗实际看到581个未连接事件。[这将是棘手的，我们的DUT配置......]
它也会帮助提到SDK，你正在使用和设备的配置，是应用程序完全运行在581上或你正在使用HCI接口，我假设应用程序完全运行在581上。[在581上运行的FW是基于5.0.4 SDK，但它已经做了大量修改。然而，大多数arch*.c文件都没有被触及。不使用人机交互。在我们的系统中，有一个应用程序运行在581上，另一个应用程序运行在不同的IC上。这两个芯片通过SPI与自定义协议通信，而不是HCI。]
你的低功耗时钟怎么样，你是用rcx还是xtal？[RCX]
一些额外的信息。暂停似乎随着更长的连接间隔消失。例如，使用47.5ms CI，在超过7小时内丢弃了一行中不超过1个从空闲数据包。我正在以更短的间隔运行进一步的测试。
我在前一条消息中的观察结果有11.25ms编程的CI。
嗨jameshiebert，
您能够在从奴隶的不活动中重新建立通信的事实意味着您在时钟侧应该可以确定，并且在问题发生时不会重置。我没有看到总体方面的奇怪，一个可能出现问题的先前交易，并影响了奴隶，所以我可以想到的唯一事情可能会导致这种情况：
结果，设备未命中活动。当前的迹线将有助于使用标识，因为如果设备通过运行代码占用，我们应该看到一个扁平的线路，只需额外的时间，我们应该看到唤醒唤醒，并且没有无线电活动（自If设备已经醒来为服务它不会启动无线电交易而迟到）。
还有什么可以帮助，如果您尝试运行一个简单的示例并检查您的HW上是否可以复制此操作，例如来自SDK的Proximity Reporter。此外，该设备是否发生了任何活动，同时发生事件，提及其连接到外部设备并通过SPI通信，因此在该时段期间在总线上有任何操作，或者可能与可以将SPI交易相关联的模式问题？也许问题与2个设备的通信之间存在某种相关性。
谢谢mt_dialog.
嗨对话框，
抱歉延迟了。我们一直在收集有关可能帮助您帮助我们的问题的一些数据。
以下是我们所知的摘要：
•暂停仅发生在设备子集（5％）中？所有设备都运行相同的应用程序SW。
•当停顿确实发生时:
〇随机发生
○暂停的持续时间取决于主服务器的SCA（请参阅附加的CI.jpg删除对话框）。
○仅在连接间隔为11.25ms（22.5ms，45ms，...）的倍数时，暂停仅发生暂停。如果协商其他CI，则无丢弃（请参阅附加的zip中的ci.jpg删除对话框）。
○当前暂停时，电流跟踪显示一致的时序，但是当暂停时，没有当前尖峰（表示Rx和TX活动）（请参阅附加的zip中的stameeause_nopause.png）。上部迹线显示CE没有暂停（代表空闲TX和RX活动的两个高尖峰），下面显示CE的暂停。时间看起来一致。
它可能是我们的应用程序SW正在做的（或不做），但对我们来说并不明显。感谢您的任何帮助，您可以提供！
“唤醒序列花费的时间超过预期(时钟设置或代码已经在唤醒序列中添加)，设备到达事件编程太晚(在power_up()函数的SLP处理程序中有一个断言，这个断言是否仍然存在于您的代码中?)”
关于您的问题，上面是关于断言的问题，这是有问题的代码吗？我将assert_warning修改为assert_error以使这种情况发生非常明显的重置。
发生暂停时，不会发生以下assert_error。
/ *
*检查BLE_SLP_IRQ是否已被断言。在这种情况下，我们延迟了periph_init（）。
*增加LP_ISR_TIME_XTAL32_CYCLES和LP_ISR_TIME_USEC值以提供更多的执行时间
* periph_init()。
* /
if（getBits32（ble_intstat_reg，slpintstat））
assert_error（0）;
嗨jamesHiebert,
从您所附的迹线看起来似乎设备正确唤醒，但显然是Rx / Tx事件的时间是错误的，最可能延迟，这是我可以提出的唯一解释，因为我可以拿出没有射频活动的唯一解释某些醒来。虽然如果这次错误，那么我提到的断言应该击中，也可以检查第二个断言是否发生在lld_sleep_compensate_func_patched（）中发生。在问题发生时，SPI设备上还有任何活动，而问题发生在问题时，也许您正在遇到的是竞争条件的一些问题，因为我无法证明为什么在使用11.25连接间隔的倍数时，设备将表现得那样。
谢谢mt_dialog.
你好再对话框中,
我们还在研究这个问题。一些新的学习，也许这将有助于你帮助我们？
休眠禁用不会发生暂停。
当退出发生时，看不到断言，包括lld_sleep_compensate_func_patched()中的断言。
我修改了现有的Rwble.c“上次事件”日志记录以将事件记录到大循环缓冲区，然后在发生丢弃时读取缓冲区。
当一切都很好，我看到ble_evt_lp，ble_evt_slp，ble_evt_cscnt，ble_evt_rx，ble_evt_tx，ble_evt_end重复。
出现丢弃时，我只看到ble_evt_lp，ble_evt_slp，ble_evt_cscnt重复。
我会检查SPI活动，但不应该有任何....
还请注意，将USE_POWER_OPTIMIZATIONS设置为0并启用延长睡眠似乎可以消除暂停/退出。我们不用深度睡眠。
嗨Jameshierbert，
当问题发生时，您只看到BLE_EVT_LP, BLE_EVT_SLP, BLE_EVT_CSCNT，这一事实只是确认了设备正常唤醒，但没有BLE
据我所知，正如以前的帖子所提到的，我可以想到的唯一原因是如果在RX / TX活动之前有延迟，这将阻止设备按时唤醒。由于您报告说，您无法从SDK所具有的已全部调试结构中看到任何断言，那么BLE_EVT_SLP和BLE_EVT_CSCNT必须有延迟。从您提供的捕获，我无法跟踪CSCNT事件，除非是CSCNT部分在最后一个凹凸中执行，我在有问题的跟踪中看到（在这种情况下失去事件是合理的）。看来SLP事件和CSCNT之间的时间似乎显着大于适当的迹线。所以在SLP之后的主要虽然SDK的功能有机会运行，你是否确定你在应用程序代码中的某些情况下你不关闭中断吗？您可以在下面的说明之后进行一些时间测量吗？
在ble_cscnt_handler（）中尝试在问题发生时记录以下值，EVT->时间（应安排下一个事件的时间）以及当前时间计数，要执行以下操作：
出于测试目的，我使用了两个16字节长度数组。
struct lld_evt_tag * evt =（struct lld_evt_tag *）co_list_pick（＆lld_evt_env.evt_prog）;
time1_log [time_idx] = EVT->时间;
time2_log [time_idx] = lld_evt_time_get（）;
time_idx + +;
time_idx& = 0 xf;
通常情况下，从time1_log收集到的值应该比当前时间值(lld_evt_time_get() time2_log)在未来至少2个槽位。如果不是，那就意味着(很可能是从应用程序级别)正在停止BLE事件的编程，而且显然BLE事件自从被延迟后就再也没有发生过。
谢谢mt_dialog.
你好对话框，
抱歉慢响应。我正在努力收集您所要求的数据，但由于实际暂停之间的滞后以及在嗅探器上注意到它时，它会产生挑战。我需要足够的缓冲空间来记录远程和内存运行低的时序数据！我会继续努力解决这个问题。
同时，我发现了以下内容：如果我在连接期间禁用SPI，则丢失停止。
如您所知，每次BLE从延长睡眠中唤醒外围设备必须重新初始化。在我们的系统中，有一个应用程序在581上运行，以及在不同的IC上运行的另一个应用程序。这两个芯片通过SPI与自定义协议进行通信。我在我们的581应用程序中放入逻辑，在扩展睡眠后停止重新启用SPI。特别是当不再运行以下代码行时，我看到暂停立即停止。
SetBits16 (SPI_CTRL_REG SPI_ON 1);
我也试过屏蔽SPI中断，并停止BLE和系统中其他芯片之间的其他GPIO中断(见下文)，但在这些情况下，暂停继续。上面是唯一的外围设备重新初始化步骤，跳过似乎可以停止暂停。
•与启用SPI中断无关
•与通过GPIO发信号通知其他芯片无关。
与SPI内部时钟分频设置无关(CLK_PER_REG从/2改为/4)
•与SPI中断优先级无关（从20到3增加）
•与clk_per_reg启用无关
•与配置SPI的GPIO引脚（输入/输出，功能等）无关
你好对话框，
请在附件中找到你在周四2018-07-12 10:36帖子中建议的计时数据。
嗨吉姆，
我将在这个问题上脱机。对于此问题之后的其他人来说，我们将无法记录我们的结果。
/ MHv