你好,对话框,
我们看到一些包含DA14581芯片的系统出现了一些奇怪的行为。在我们的系统中，DA14581是从设备，不同的供应商提供主BLE芯片。
在少数这样的系统中，我们观察到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配置的设备表现出dropout行为。]
表现出这种行为的设备是独特的，我的意思是，您是否在多个设备上的类似环境中执行了这个测试，并且在连续的测试中只有一个(例如)设备暴露了这种行为?(正确的。在一个特定的环境中，有一个实验室，有十几个相同的测试站，所有的DUT与从属581芯片，只有一个DA14581表现出行为。我们用不同的电路板(不同的581)交换电路板，问题就解决了。这种情况也发生在其他环境中。该行为遵循581(或至少是它被焊接的电路板)。
还有，有关联的大师呢?这种行为是否与特定的主链接相关，或者无论链接的主链接是什么都会发生?我们绝大多数的主设备都是相同的定制设备。也有一些例外——商用智能手机。我将用已知的“失败的”DA14581和一部智能手机做一个实验。]
当事件发生时，你有可分享的嗅探器痕迹吗?[我附上了一个有2个中途退出的跟踪。我们使用Teledyne LeCroy ComProbe协议分析系统。你能看懂那些文件吗?］
．．．您是否已经验证了这个副作用是由于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)
一些额外的信息。当连接间隔变长时，暂停似乎会消失。例如，在超过7小时的时间里，在47.5ms CI的情况下，一行中没有超过1个从属空闲包被丢弃。我在用更短的间隔做进一步的测试。
我在之前的消息中观察到的CI为11.25ms。
嗨JamesHiebert,
事实上，你能够重新建立通信后超过1秒的不活动的奴隶意味着你应该是ok的时钟方面，没有复位，而问题发生。我没有看到任何奇怪的从主端，前一个事务可能会出错和影响奴隶，例如，我能想到的唯一可能导致这种情况的事情是:
因此，设备会错过事件。电流跟踪会帮助使用识别,因为如果设备是通过运行代码占领我们应该看到一个平坦的线条就消费如果启动FSM花了额外的时间我们应该看到醒来,没有无线电活动醒来后(因为如果设备维修迟到事件它不会开始广播事务)。
如果您尝试运行一个简单的示例，并检查是否可以在您的hw上复制它，例如，SDK中的接近报告程序，也会有帮助。另外，当事件发生时，设备是否有任何活动，您提到它连接到外部设备并通过SPI进行通信，那么在此期间总线上是否有任何操作，或者可能有一个模式可以将SPI事务与问题关联起来?也许在这个问题和两个设备的通信之间存在某种关联。
由于MT_dialog
嗨,对话框中,
对不起，耽搁了这么久。我们一直在收集关于这个问题的一些数据，这些数据可能会对你们有所帮助。
以下是我们所知的概要:
•暂停只发生在一个设备子集(5%)?所有设备都在运行相同的应用程序SW。
•当暂停发生时:
〇随机发生
〇暂停的持续时间取决于大师的SCA(参见附件中的CI.jpg Dialog Drop-outs)。
〇只有当“连接间隔”为11.25ms (22.5ms, 45ms，…)的倍数时，才会出现暂停。如果协商了其他CI，没有退出(见附件zip中的CI.jpg Dialog drop-outs)。
〇当暂停发生时，当前跟踪显示一致的时间，但没有当前峰值(代表RX和TX活动)(见附件zip中的ComparePause_NoPause.png)。上面的轨迹显示没有暂停的CE(可以看到两个代表空闲TX和RX活动的高峰值)，下面的轨迹显示有暂停的CE。时机似乎是一致的。
这可能是我们的应用程序SW正在做(或没有做)的事情，但对我们来说并不明显。感谢您提供的任何帮助!
唤醒序列花费的时间超过预期(时钟调整或在唤醒序列中添加了代码)，设备到达事件编程太晚(在power_up()函数的SLP处理程序中有一个断言，该断言仍然存在于您的代码中吗?)
关于你上面关于断言的问题，这是问题代码吗?我将ASSERT_WARNING修改为ASSERT_ERROR，以便在发生这种情况时引起非常明显的重置。
当暂停发生时，下面的ASSERT_ERROR不会发生。
／＊
*检查BLE_SLP_IRQ是否已经断言。在本例中，我们延迟了peripher_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设备上的任何活动,与581年当问题发生时,也许你正在经历都是某种竞争条件,因为我无法解释为何当使用倍数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部分在我看到的有问题的跟踪中的最后一个bump中执行(在这种情况下，失去事件是合理的)。从跟踪来看，SLP事件和CSCNT之间的时间明显大于适当的跟踪。因此，在SLP之后，SDK的主要while函数就有机会运行了，你确定在应用程序代码中的某些条件下不会关闭中断吗?你能按照下面的说明测量一些时间吗?
在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