不能使用GTL进入延长睡眠

**请您优先处理这个线程**
更好的是，我们可以把讨论离线作为支持票，还是通过电话/skype来讨论?

我们已经完成了硬件设计和构建，并且非常接近完成固件开发。您的回答似乎表明我们有一个阻塞问题，可能需要我们切换到不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。

我们目前使用的架构与UM-B-017中所附的图表(jpg格式zip)非常相似，标题为“集成处理器应用中的DA14580/581 GTL接口”。亚博国际官网平台网址我们有一个集成的处理器应用程序(即“任务应用程序”)和一个GTL接口，如文档所描述的。

唯一的区别是我们使用SPI进行外部通信，而不是UART，并且我们不使用显式的Wakeup GPIO(我们使用DREADY来实现此目的)。

您能否确认:您是否在之前的回复中说，在集成处理器应用程序中不可能使用GTL接口?上面的架构不受支持?或者也许我们误解了这份文件及其含义?

我们使用文档第5节中描述的传输格式，我们在app.h中定义自己的一组应用程序级消息和处理程序，如第6节中定义的那样。第7节讨论了在使用GTL时的最大睡眠时间，但我们还没有讲到这一点。我们的代码是稳定的，已经运行了一段时间，通过GTL消息到我们的外部MCU。然而，我们的应用程序不会进入(扩展的)睡眠。

如果所附图表中的体系结构受支持，您能否帮助我们了解需要进行哪些更改才能实现所述的体系结构？我们需要一个TASK_应用程序（如图所示）来处理与概要文件相关的消息交换（创建_db、启用/禁用、写入指示等），另外还需要一个GTL接口，以便在特定应用程序级事件发生时以较低的频率与外部处理器交换高级消息。我们还支持DISS和BASS配置文件（将来可能会添加其他配置文件）。

我们发现有关CFG_应用程序的文档令人困惑。config_basic.h文件中的注释是

/***************************************************************************************************************/
/*集成或外部处理器配置*/
/* -defined集成处理器模式。主机应用程序运行在DA14580处理器上。主机应用程序* /
/*是TASK_APP内核任务。*／
/*-未定义的外部处理器模式。主机应用程序在外部处理器上运行。与*/
/*通过GTL协议通过信令iface (UART, SPi等)的BLE应用程序*/
/***************************************************************************************************************/

然而，在上述文件中，它说:
如果未定义，它将允许在“集成处理器应用程序”中与外部处理器的应用任务通过GTL/UART接口进行通信。

如能及时答复，将不胜感激。
保罗。

谢谢你的回复。你对TASK_APP和TASK_GTL如何为我们工作的假设是正确的，除了我们发送给TASK_GTL的消息与我们接收到的TASK_APP不同:它们是我们自己定义的更高级别的特定于应用程序的消息。与UM-B-017中描述的类似，并使用那里设置的方法。例如:单片机的初始化连接数据库(由外部单片机存储),启动/停止不同类型的广告,把当前的电池电压水平(这是由单片机感觉到),和DA14580将固件更新数据包发送到单片机无线固件更新,等等。

当我们试图休眠时，没有GTL消息挂起或在传输中。GTL消息不是特别经常发送-通常只是在启动时间，当有一个连接在进行中，最终用户正在进行数据同步或固件更新。

大多数时候，设备不是处于连接状态，也不是在发布信息。它将只是在睡眠中等待来自MCU的唤醒信号(该设备是运动敏感的，在运动中醒来)。在其他时间，它是广告和睡眠是需要保存电力。

请注意，我们正在使用Segger J-Link调试器对PAN1740ETU评估模块进行测试，并且在我们自己的板上。

我们确实看到，在播放广告时，每376ms和连接时，每48.75ms会有一次对应用程序上的应用程序和系统上的应用程序的调用。

下面是一些具体的问题:

1)如果我们的场景/架构是罕见的和未经测试的，为什么会有一个文档UM-B-017，标题为“DA14580/581 GTL接口在集成处理器应用”，专门描述它?亚博国际官网平台网址我们是否误解了这份文件?它似乎准确地代表了这个体系结构并描述了如何使用它。

2)由于没有GTL活动在适当的地方或悬而未决，您能帮助我们了解什么可能阻止设备睡眠?这是我们现在要回答的最重要的问题。我们需要测试什么?我们能做什么?

3)如果我们定义CFG_DEVELOPMENT_DEBUG #并调试主循环，我们认为我们看到它在rwip_prevent_sleep_get()中没有进入sleep。你能解释一下吗?会和GTL有关吗?它深入到SDK实现中，对我们来说很难调试。

4） 我们使用的是SDK 5.0.4-这可以让开发调试继续吗？

谢谢
保罗

根据你的建议，我已经将CFG_DEVELOPMENT_DEBUG放在上面并调试了睡眠代码/问题。

1)为了检测睡眠，我使用。app_going_to_sleep和。app_resume_from_sleep上设置的回调来切换GPIO行以指示睡眠。仔细检查发现，这些函数被编译器优化了。在调用这些函数时，外围设备似乎已经关闭了，因此编译器删除了代码(令人惊讶)。我将代码移动到在禁用外设之前切换GPIO行，这个方法用于指示睡眠。

2)在rwip_sleep()中有三个地方阻止它睡觉。
a) rwip_prevent_sleep_get()测试
b） 通过（ble_intrawstat_get（）&ble_GROSSTGTIMINTRAWSTAT_BIT）测试内核计时器
c)与上面一样——但这是对内核计时器的第二次测试。
随着这三个测试的注释掉，设备确实进入了长时间的睡眠。当我连接时，我看到它在48毫秒的连接事件中睡着和醒着。如果我关闭广告，那么它将按照CFG_MAX_SLEEP_DURATION_PERIODIC_WAKEUP_MS定时器休眠和唤醒。我目前将这个设置为60万(10分钟)，工作正常(最初的值是500秒)。

3） 在每个唤醒/休眠期间，再次启用GTL接口。但有一个问题。每次发送两个flow-on字节，然后在设备再次休眠时发送flow-off。这会导致MCU上的GTL协议代码出现问题-你能不能帮我看看这个能不能修好?请看附呈的图。我怀疑这是由于flow_on被直接通过jump_table调用，然后可能作为gtl_exit_sleep()的一部分再次调用;但是，我不能调试到跳转表之前。你能解释一下这里发生了什么，谁调用了这些跳转表函数，以及我如何调试它们吗？．我也没有任何代码的gtl.c。这是可用的吗?

4)如果我将restore rwip.c恢复到它原来的状态，那么如上所述，没有睡眠。然而，在第一个GTL消息被发送之后，sleep开始正常工作。所以我认为GTL一开始就被认为处于错误的状态是有问题的。也许这与上面的flow_on问题有关。你能不能看一看，看看这个是否可以改进，或者变通一下?

谢谢
保罗

感谢您修复了双流动问题。这解决了我的一个问题。
另一个问题仍然存在。让我来总结:

我们使用GTL和一个集成处理器(TASK_APP)。TASK_APP通过GTL向外部处理器发送消息，以执行高级应用程序特定的任务。
我们已经配置了延长睡眠时间。
当我们开始的时候，地检官不会睡觉。它会做广告、连接和正常工作，但它不会睡觉。
如果我们从一个移动设备连接到它，并写入一个特征(控制点)，导致一个GTL消息被DA发送到MCU主机，然后立即在这个GTL消息被发送后DA开始休眠。我们看到它在每个连接事件中都是醒着的。如果我们断开手机，我们会看到它在每次广告活动中都会醒来。它的工作原理和我们预期的一样，在事件之间睡觉。我们甚至可以让它在没有广告的情况下休眠，并通过GPIO引脚上的外部唤醒事件唤醒它。
所以我们认为这个问题是由GTL消息和GTL状态引起的。我们没有显式地使用任何内核计时器。

在调试之后，我们看到rwip.c中它不会休眠的两个原因。

If (rwip_prevent_sleep_get() != 0)
打破;

这一行阻止了它进一步(即执行break)。这是因为rwip_prevent_sleep_get()返回RW_GTL_TIMEOUT。所以我们使用

rwip_prevent_sleep_clear (RW_GTL_TIMEOUT);

在我们的初始化代码中，这一行不再阻止我们睡觉。

第二个问题是

if (ble_intrawstat_get() & ble_grosstgtimmintrawstat_bit)
打破;

BLE_GROSSTGTIMINTRAWSTAT_位已设置并防止睡眠。我们没有关于此位的太多数据，并且在代码中的任何地方都没有显式设置。我们已尝试使用

REG_BLE_WR (BLE_INTRAWSTAT_ADDR BLE_INTRAWSTAT_RESET);

在我们的初始化代码，但这没有帮助-它是在别处设置的。

您能否提供更多关于这个位的信息，它在做什么，它是如何设置的，以及它可能如何与GTL接口相关。或者——更好的是——你能像之前的问题一样提出一个解决方案吗?

谢谢
保罗。

对话-对上述问题有帮助的机会吗？
这阻碍了我们的发展，我们没有多少时间了!

非常感谢,
保罗。

是的，这就是我们现在的工作方式。我们通过移动设备连接到设备，然后手动发送虚拟消息。然后，这将启动设备正常睡眠。

保罗

对你的建议进行试验后，我们找到了解决办法。我们向MCU发送了一个初始的READY消息，并接收回一个INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样直接进入睡眠(在2秒延迟之后)。如果在user_app_on_db_init_complete()期间发送READY消息，那么sleep仍然按照预期工作。因此，通过延迟READY消息，问题似乎得到了解决。

谢谢
保罗