我们在PAN1740模块上运行了一个应用程序。我们在DA14580上处理大多数消息，但我们有一个通过SPI到MCU的外部接口。通信使用GTL(即集成处理器应用程序的GTL接口)。
我们现在正在尝试让我们的工作应用程序运行与延长睡眠启用。我相信我们有正确的定义…
#定义CFG_GTL_SPI
#定义CFG_APP
#定义CFG_集成_主机_GTL
#定义CFG\u MEM\u MAP\u EXT\u SLEEP
#undef CFG_MEM_MAP_DEEP_SLEEP
#undef CFG_开发_调试
const static sleep\u state\u t app\u default\u sleep\u mode=ARCH\u EXT\u sleep\u ON；
我们在.app_going_to_sleep和.app_resume_from_sleep上设置了回调以打开和关闭GPIO行以指示睡眠，但我们没有看到这样的更改。
部分问题是，我们无法调试主循环，以理解为什么它不休眠，因为我们需要关闭调试。
如果我们定义CFG_DEVELOPMENT_DEBUG #并调试主循环，我们*认为*我们看到它未能在rwip_prevent_sleep_get()上进入sleep。
我们怀疑是GTL的存在。这可能吗？我们如何让睡眠模式工作？
谢谢
保罗。
设备：
嗨，梅勒，
您必须选择您的设备是使用GTL(使用外部处理器)工作，还是使用应用程序级模块(启用APP_TASK，独立配置)。您不能同时拥有两者，这是CFG_APP定义所规定的。如果定义了CFG_APP，那么您将处于集成处理器模式;如果未定义，那么您将处于外部模式。
谢谢你的对话
**请您优先处理这个线程**
更好的是，我们可以把讨论离线作为支持票，还是通过电话/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接口进行通信。
如能及时答复，将不胜感激。
保罗。
嗨，梅勒，
通常SDK做事是如何推动TASK_GTL或者TASK_APP,我们不该有任何项目,使用两种SDK的报告在一个应用程序任务中,我一看代码和显然它可能是合理的(从来没有测试在实际领域,我提到的是只是一个理论)。如果你正在做的事情是工作我将假设您已经定义的CFG_APP从堆栈中每条消息的应用程序将最终TASK_APP,为了获取一些消息GTL任务我假设你把消息从TASK_APP回栈TASK_GTL作为接收器,所以这就是你在你的项目中所做的，因为这是我认为唯一可行的方法?
关于睡眠，是的，GTL可能会影响设备的睡眠，如果设备的传输尚未结束，并且仍有待发送的数据，则设备将保持清醒，直到它们结束。关于调试和睡眠，如果您使用的是最新的SDK，这应该是可以做到的。
谢谢你的对话
谢谢你的回复。你are right in your assumptions about how TASK_APP and TASK_GTL are working for us, except that the messages we send to TASK_GTL are not the same ones we receive as TASK_APP: they are higher level application-specific messages that we define ourselves. Similar to those described in UM-B-017 and using the method set out there. For example: for the MCU to initialise the bonding database (which is stored by the external MCU), to start/stop different types of advertising, to put the current battery voltage level (again this is sensed by the MCU), and for the DA14580 to send firmware update packets to the MCU for over-the-air firmware update, and so on.
当我们尝试睡眠时，没有挂起或正在传输的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-这可以让开发调试继续吗？
谢谢
保罗
嗨，梅勒，
1)文档,你参照位于停止相关的文档的支持网站SDK3,显然这种架构是abandonded当搬到一个新的SDK(这不是用作据我所知)但是functionallity仍然在新的SDK,就我所知，你没有误解的文件，显然你可以有这种配置，甚至在SDK 5，为误解和我仓促的回答道歉。
2-3) CFG_DEVELOPMENT_DEBUG定义，它所做的就是在fw运行时删除任何断言，而且在深度睡眠的情况下，它会关闭整个系统，我没有发现睡眠和该标志之间的任何关系。你能告诉我你是如何确定设备处于休眠状态和处于醒着状态的吗?我的意思是你是通过功率分析器测量的，还是通过DMM测量的?rwip_prevent_sleep_get()应该去休息,如果有一些防止设备睡觉这与RW堆栈或gtl接口但仍然我不看到任何关系berween和CFG_DEVELOPMENT_DEBUG(你看到任何改变在睡眠和CFG_DEVELOPMENT_DEBUG)之间的行为。一个想法来检查这是地方的brakepoint rwip_sleep底部()函数的函数,它是决定设备确实是要适量后睡眠条件检查,如果你遇到断点的设备是睡觉。
4） SDK5.0.4是唯一能够在睡眠模式下运行调试的SDK。
谢谢你的对话
根据你的建议，我已经将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消息后，睡眠开始正常工作。因此，我认为GTL在最初被认为处于错误状态时一定存在问题。这可能与上述问题的流程有关。你能不能看一看，看看这个是否可以改进，或者变通一下?
谢谢
保罗
嗨，梅勒，
2-3）rwip_sleep（）具有上述所有检查，以查看上述任何一项是否有挂起的过程，如果有，则不会进入睡眠状态，因此不建议评论这些情况，因为无论是否有事情要做，设备都将进入睡眠状态。为了让设备进入睡眠状态，它会通过这些检查并做出决定。您是否看到，该设备总是中断，并且从未达到程序核心深度睡眠，这将发出睡眠期即将结束的信号？如果您提到由于内核计时器中的错误，设备正在取消睡眠，请检查如果您从项目中删除计时器（如果您正在使用任何计时器）（仅用于测试），会发生什么情况？另外，您是否可以卸下GTL并检查设备是否仍具有相同的行为？只需尝试将应用程序用作独立设备，并验证该设备是否进入睡眠模式。然后，您可以重新应用GTL配置，并检查GTL是否导致睡眠问题。尝试查看是否有来自外部主机的任何挂起命令或接口中保持设备唤醒的信号。
我能够使用ble_app_外围设备示例并在该项目上应用SPI GTL配置，然后我使用Proxity reporter主机项目（另一个580上的host_proxr项目）作为完全嵌入/GTL修改项目上的主机，当应用程序从外部主机启动时，我在睡眠中找不到任何问题（在编写自定义特征时，从完全托管项目的TASK_应用程序向主机发送GTL消息）。
4)关于您报告的问题,这是一个已知的问题与GTL SPI是的它发送一个副本流在传输设备是醒来时,就我所知是没有采取行动,解决问题(可以肯定的是检查),你可以尝试作为一个工作周围将是添加一个计数器，以避免在字节上发出流超过必要的次数，如下所示:
在spi_hci_flow_off_func()中应用以下内容
if（0==流量
{
返回true;
}否则
{
flow_on_cnt——;
}
在spi_hci_flow_on_func（）中应用以下内容
如果（流量>0）
{
回来
}否则{
flow_on_cnt + +;
}
这不是一个经过验证或测试的解决方案，但您可以尝试这样做，以避免在信号上有两个流。
谢谢你的对话
感谢您修复的双流问题。这解决了我的一个问题。
另一个问题仍然存在。让我来总结:
我们使用GTL和集成处理器（TASK_应用程序）。TASK_APP通过GTL向外部处理器发送消息，以执行高级应用程序特定任务。
我们已经配置了延长睡眠时间。
当我们启动时，DA不睡觉。它将进行广告宣传、连接并正常工作，但它不会睡眠。
如果我们从移动设备连接到它，并写入导致DA向MCU主机发送GTL消息的特征（控制点），则在发送该GTL消息后，DA立即开始正常睡眠。我们看到它为每个连接事件唤醒。如果我们断开手机的连接，我们会看到每次广告活动都会唤醒手机。它的工作原理和我们预期的一样，在事件之间睡觉。我们甚至可以让它在没有广告的情况下睡觉，并通过GPIO引脚上的外部唤醒事件唤醒它。
所以我们认为这个问题是由GTL消息和GTL状态引起的。我们没有显式地使用任何内核计时器。
在调试之后，我们看到rwip.c中它不会休眠的两个原因。
If (rwip_prevent_sleep_get() != 0)
打破
这一行阻止它进一步移动（即执行中断）。这是因为rwip_prevent_sleep_get（）返回RW_GTL_TIMEOUT。所以我们用
rwip_防止_睡眠_清除（RW_GTL_超时）；
在我们的初始化代码中，这一行不再阻止我们睡觉。
第二个问题是与
if（ble_intrawstat_get（）&ble_GROSSTGTIMINTRAWSTAT_位）
打破
BLE_GROSSTGTIMINTRAWSTAT_位已设置并防止睡眠。我们没有关于此位的太多数据，并且在代码中的任何地方都没有显式设置。我们已尝试使用
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）；
在我们的初始化代码，但这没有帮助-它是在别处设置的。
您是否可以帮助了解更多关于该位的信息，它正在做什么，它是如何设置的，以及它与GTL接口的关系。或者，更好的是，您是否可以像对上一个问题一样提出修复建议？
谢谢
保罗。
对话-对上述问题有帮助的机会吗？
这阻碍了我们的发展，我们没有多少时间了!
非常感谢,
保罗。
嗨，梅勒，
您提到的设备停止部分用于检查设置的计时器，如果计时器即将过期，则设备将取消休眠过程。由于设备在GTL层上进行消息交换时进入休眠状态，您是否尝试在设备和主机之间交换虚拟消息并检查这会迫使设备进入睡眠状态吗？
谢谢你的对话
是的，这就是我们现在的工作方式。我们通过移动设备连接到设备，然后手动发送虚拟消息。然后，这将启动设备正常睡眠。
保罗
嗨，梅勒，
我的意思是,只要我能理解从上面的描述中,由于某些原因,我不能确定,因为我不能够复制在我的设置,设备保持活跃,显然您发送或接收GTL消息后设备运行。所以我建议的是测试情况时，设备没有连接，例如发送一个假的GTL消息到外部MCU，一旦设备得到配置或一旦设备创建它的数据库。此外，设备上是否有任何外部唤醒配置，如果有，请删除该功能，并检查是否产生了您正在经历的副作用?
谢谢你的对话
对你的建议进行试验后，我们找到了解决办法。我们向MCU发送了一个初始的READY消息，并接收回一个INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样直接进入睡眠(在2秒延迟之后)。如果在user_app_on_db_init_complete()期间发送READY消息，那么sleep仍然按照预期工作。因此，通过延迟READY消息，问题似乎得到了解决。
谢谢
保罗
嗨，梅勒，
谢谢你告诉我们，很高兴你弄明白了。
谢谢你的对话