你好对话框，
我们正在看到一些奇怪的行为，其中一些包含DA14581芯片的系统。在我们的系统中，DA14581是从设备，不同的供应商提供主芯片芯片。
在少数这样的系统上，我们观察到从DA14581的空的PDU传输中随机暂停。连接了BLE包嗅探器迹线。随机丢失在轨迹中可见，作为吞吐量的液滴。每个暂停始终始终为1.1 - 1.2秒。在跟踪时没有交换应用层流量 - 这些都是空闲数据包。
Our systems should be built and configured identically. The application running at the time of the trace was downloaded via the IDE (NOT running out of OTP) This behavior is only exhibited in a small minority of such systems. Slave latency is set to 0 for all (confirmed multiple times!).
任何可能对此行为背后的想法？在这些情况下，它导致连接下降。
谢谢，
吉姆
附件：
设备：
嗨jameshiebert，
因此，这种行为在共享相同构建和FW的设备上随机展出？这是正确的吗 ？我的意思是展示此行为的设备是唯一的，您的意思是您是否在多个设备上对类似的环境进行了此测试，并且只有一个（例如）设备在连续测试中暴露此行为？掌握连接的情况怎么样？是否与特定主站相关的此行为，或者，无论链接的主人如何，都会发生这种情况？
您是否有实际的嗅探器跟踪在发生事件时分享并验证此副作用是由于Sniffer日志的错过事件，因此您可以看到来自主站的数据包，没有数据包奴隶一侧？您已从吞吐量中附加了一个图表，但这并不有助于找到一个根本原因，有什么帮助是当前问题时的当前捕获，并且实际上看到581通过功耗错过了连接事件。此外，它还有助于提及您使用的SDK以及设备的配置，是应用程序完全在581上运行的应用程序，也可以使用HCI接口，我假设该应用程序完全运行在581上。你的低功耗时钟怎么样，你是用rcx还是xtal？
谢谢mt_dialog.
嗨对话框，
因此，这种行为在共享相同构建和FW的设备上随机展出？这是正确的吗 ？[是的。具有完全相同的HW和FW配置的少数（少量百分比）展示了丢失行为。]
我的意思是展示此行为的设备是唯一的，您的意思是您是否在多个设备上对类似的环境进行了此测试，并且只有一个（例如）设备在连续测试中暴露此行为？[正确的。在一个特定的环境中，有一个具有十几个或如此相同的测试站的实验室，所有具有具有从581芯片的DUT，并且只有一个DA14581表现出行为。我们将电路板与不同的板（不同581）交换，问题消失了。它也发生在其他环境中。该行为遵循581（或至少焊接的电路板）。]
掌握连接的情况怎么样？是否与特定主站相关的此行为，或者，无论链接的主人如何，都会发生这种情况？[The vast majority of our master devices are identical custom built boxes. There are a few outliers - commercial smart phones. I'll run an experiment with a known "failing" DA14581 and a smartphone.]
当发生事件发生时，您是否有实际的嗅探器迹象？[我附着一条带有2个辍学的痕迹。我们使用Teledyne LeCroy Thexobe协议分析系统。你能读过这些文件吗？]
......你已经验证了这个副作用是由于581的一侧错过的事件，所以在嗅探器日志上，您可以看到来自主站的数据包，从奴隶侧没有数据包？[这也是正确的。主机继续发送空闲数据包，没有来自DA14581的响应。这些间隔有点随机发生，但总是持续约1.1-1.2秒。]
您已从吞吐量中附加了一个图表，但这并不有助于找到一个根本原因，有什么帮助是当前问题时的当前捕获，并且实际上看到581通过功耗错过了连接事件。[这将是棘手的，我们的DUT配置......]
此外，它还有助于提及您使用的SDK以及设备的配置，是应用程序完全在581上运行的应用程序，也可以使用HCI接口，我假设该应用程序完全运行在581上。[581上运行的FW基于5.0.4 SDK，但它已被严重修改。然而，大多数arch * .c文件都是不受欢迎的。没有使用HCI。在我们的系统中，有一个应用程序在581上运行，以及在不同的IC上运行的另一个应用程序。这两个芯片通过SPI与自定义协议进行通信，而不是HCI。]
你的低功耗时钟怎么样，你是用rcx还是xtal？[RCX]
一些额外的信息。这pauses seem to disappear with longer Connection Intervals. For instance, no more than 1 slave idle packet in a row was dropped in over 7 hours with a 47.5ms CI. I am running further tests with shorter intervals.
我在前一条消息中的观察结果有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删除对话框）。
○ A current trace shows consistent timing but no current spikes (representing RX and TX activity) when the pauses occur (see ComparePause_NoPause.png in attached zip). The upper trace shows CE's without pauses (two tall spikes representing idle TX and RX activity are seen), and the lower shows CE's with pauses. The timing looks consistent.
它可能是我们的应用程序SW正在做的（或不做），但对我们来说并不明显。感谢您的任何帮助，您可以提供！
“唤醒序列需要超过预期的（时钟沉降或代码已在唤醒序列中添加），并且设备到达事件的编程太晚（Power_up（）函数中的SLP处理程序中存在断言，是断言仍然存在于您的代码上吗？）“
关于您的问题，上面是关于断言的问题，这是有问题的代码吗？我将assert_warning修改为assert_error以使这种情况发生非常明显的重置。
发生暂停时，不会发生以下assert_error。
/ *
*检查BLE_SLP_IRQ是否已被断言。在这种情况下，我们延迟了periph_init（）。
*增加LP_ISR_TIME_XTAL32_CYCLES and LP_ISR_TIME_USEC values to give more execution time
*到periph_init（）。
* /
if（getBits32（ble_intstat_reg，slpintstat））
assert_error（0）;
嗨jameshiebert，
从您所附的迹线看起来似乎设备正确唤醒，但显然是Rx / Tx事件的时间是错误的，最可能延迟，这是我可以提出的唯一解释，因为我可以拿出没有射频活动的唯一解释某些醒来。虽然如果这次错误，那么我提到的断言应该击中，也可以检查第二个断言是否发生在lld_sleep_compensate_func_patched（）中发生。在问题发生时，SPI设备上还有任何活动，而问题发生在问题时，也许您正在遇到的是竞争条件的一些问题，因为我无法证明为什么在使用11.25连接间隔的倍数时，设备将表现得那样。
谢谢mt_dialog.
你好，对话，
我们还在研究这个问题。一些新的学习，也许这将有助于你帮助我们？
这pauses do not occur with sleep disabled.
当丢失发生时，没有断言，包括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_OPTIMIZITATIANTS设置为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＆= 0xF;
通常，从时间1_log收集的值应该是未来的至少2个插槽，而不是当前时间值（lld_evt_time_get（）time2_log）。如果不是那么意味着这意味着某种东西（大多数可能来自应用程序级别）正在停止BLE事件的编程，并且显然从它延迟时不会发生BLE事件。
谢谢mt_dialog.
你好对话框，
抱歉慢响应。我正在努力收集您所要求的数据，但由于实际暂停之间的滞后以及在嗅探器上注意到它时，它会产生挑战。我需要足够的缓冲空间来记录远程和内存运行低的时序数据！我会继续努力解决这个问题。
In the mean time, I've discovered the following: if I disable SPI during a connection the dropouts cease.
如您所知，每次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引脚（输入/输出，功能等）无关
你好对话框，
请在The The Contrated在Thu，2018-07-12 10:36帖子中提出收集的时序数据，查找附件。
嗨吉姆，
我将在这个问题上脱机。对于此问题之后的其他人来说，我们将无法记录我们的结果。
/ mhv.