你好,对话框,
我们在一些包含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的设备上随机表现出来的?是这样吗?(是的。少量(极少数)与FW配置完全相同的设备会出现dropout行为。]
表现出这种行为的设备是独特的，我的意思是，你是否在类似的环境中在多个设备上执行了这个测试，而在连续的测试中只有一个(例如)设备暴露了这种行为?(正确的。在一个特定的环境中，有一个实验室，里面有十几个相同的测试站，都有一个带有从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,
您能够在从奴隶的不活动中重新建立通信的事实意味着您在时钟侧应该可以确定，并且在问题发生时不会重置。我没有看到总体方面的奇怪，一个可能出现问题的先前交易，并影响了奴隶，所以我可以想到的唯一事情可能会导致这种情况：
导致设备丢失事件。电流跟踪会帮助使用识别,因为如果设备是通过运行代码占领我们应该看到一个平坦的线条就消费如果启动FSM花了额外的时间我们应该看到醒来,没有无线电活动醒来后(因为如果设备维修迟到事件它不会开始广播事务)。
还有什么可以帮助，如果您尝试运行一个简单的示例并检查您的HW上是否可以复制此操作，例如来自SDK的Proximity Reporter。此外，该设备是否发生了任何活动，同时发生事件，提及其连接到外部设备并通过SPI通信，因此在该时段期间在总线上有任何操作，或者可能与可以将SPI交易相关联的模式问题？也许问题与2个设备的通信之间存在某种相关性。
谢谢mt_dialog.
嗨对话框，
对不起，让您久等了。我们一直在收集有关这个问题的数据，这些数据可能会帮助你帮助我们。
以下是我们所知的概要:
•暂停只发生在一部分设备中(5%)?所有设备都运行相同的应用程序软件。
•当停顿确实发生时:
○随机发生
〇暂停的持续时间取决于主SCA(参见附件中CI.jpg的Dialog Drop-outs)。
〇“连接间隔”为11.25ms (22.5ms, 45ms，…)的倍数时才会暂停。如果其他CI的协商，没有退学(见附件zip中的Dialog dropout by CI.jpg)。
○当前暂停时，当前迹线显示一致的时序，但是当前暂停时上部迹线显示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“last event”日志，将事件记录到一个大型循环缓冲区中，然后在发生退出时读取缓冲区。
当一切都很好，我看到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 enable无关
•与配置SPI的GPIO引脚(输入/输出，功能等)无关
你好,对话框,
请在附件中找到你在周四2018-07-12 10:36帖子中建议的计时数据。
嗨,吉姆,
我将离线处理这个问题。对于其他关注这个问题的人，我们将确保记录我们的结果。
/ MHv