我们在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（）进入睡眠状态。
我们怀疑是GTL的存在。这可能吗？我们如何让睡眠模式工作？
谢谢
保罗。
设备：
嗨，梅勒，
您必须选择您的设备是使用GTL(使用外部处理器)工作，还是使用应用程序级模块(启用APP_TASK，独立配置)。您不能同时拥有两者，这是CFG_APP定义所规定的。如果定义了CFG_APP，那么您将处于集成处理器模式;如果未定义，那么您将处于外部模式。
谢谢你的对话
**你能给这条线定个轻重缓急吗**
更好的是，我们是否可以将讨论作为支持票离线，或者通过电话/skype进行讨论？
我们已经完成了硬件设计和构建，并且非常接近完成固件开发。您的回答似乎表明我们有一个阻塞问题，可能需要我们切换到不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。
我们目前使用的架构非常类似于UM-B-017中所示的附图（zip格式的jpg），其标题为“集成处理器应用中的DA14580/581 GTL接口”。正如文件所述，我们有一个集成处理器应用程序（即“任务应用程序”）和一个GTL接口。亚博国际官网平台网址
唯一的区别是，我们使用SPI进行外部通信，而不是UART，并且我们不使用显式唤醒GPIO（为此我们使用了DREADY）。
您是否可以确认：您是否在之前的回复中说过，在集成处理器应用程序中不可能使用GTL接口？是否不支持上述体系结构？或者我们误解了这份文件及其含义？
我们使用文档第5节中描述的传输格式，我们在app.h中定义自己的一组应用程序级消息和处理程序，如第6节中定义的那样。第7节讨论了在使用GTL时的最大睡眠时间，但我们还没有讲到这一点。我们的代码是稳定的，已经运行了一段时间，通过GTL消息到我们的外部MCU。然而，我们的应用程序不会进入(扩展的)睡眠。
如果所附图表中的体系结构受支持，您能否帮助我们了解需要进行哪些更改才能实现所述的体系结构？我们需要一个TASK_应用程序（如图所示）来处理与概要文件相关的消息交换（创建_db、启用/禁用、写入指示等），另外还需要一个GTL接口，以便在特定应用程序级事件发生时以较低的频率与外部处理器交换高级消息。我们还支持DISS和BASS配置文件（将来可能会添加其他配置文件）。
我们发现有关CFG_应用程序的文档令人困惑。config_basic.h文件中的注释是
/***************************************************************************************************************/
/*集成或外部处理器配置*/
/* -defined集成处理器模式。主机应用程序运行在DA14580处理器上。主机应用程序* /
/*是应用程序内核任务的任务*/
/*-未定义的外部处理器模式。主机应用程序在外部处理器上运行。与*/
/*通过GTL协议在信令iface（UART、SPi等）上的BLE应用*/
/***************************************************************************************************************/
但在上面提到的文件中，它说：
“如果未定义，它将启用*集成处理器应用程序*中的应用程序任务通过GTL/UART接口与外部处理器的通信。”
如能及时答复，将不胜感激。
保罗。
嗨，梅勒，
通常SDK做事是如何推动TASK_GTL或者TASK_APP,我们不该有任何项目,使用两种SDK的报告在一个应用程序任务中,我一看代码和显然它可能是合理的(从来没有测试在实际领域,我提到的是只是一个理论)。如果你正在做的事情是工作我将假设您已经定义的CFG_APP从堆栈中每条消息的应用程序将最终TASK_APP,为了获取一些消息GTL任务我假设你把消息从TASK_APP回栈TASK_GTL作为接收器,所以这就是你在你的项目中所做的，因为这是我认为唯一可行的方法?
关于睡眠，是的，GTL可能会影响设备的睡眠，如果设备的传输尚未结束，并且仍有待发送的数据，则设备将保持清醒，直到它们结束。关于调试和睡眠，如果您使用的是最新的SDK，这应该是可以做到的。
谢谢你的对话
谢谢你的回复。关于TASK_应用程序和TASK_GTL如何为我们工作，您的假设是正确的，只是我们发送给TASK_GTL的消息与我们作为TASK_应用程序接收的消息不同：它们是我们自己定义的更高级别的应用程序特定消息。与UM-B-017中描述的类似，并使用此处规定的方法。例如：MCU初始化绑定数据库（由外部MCU存储）、启动/停止不同类型的广告、输入当前电池电压水平（同样由MCU检测）、DA14580向MCU发送固件更新数据包以进行无线固件更新，等等。
当我们尝试睡眠时，没有挂起或正在传输的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（）处进入睡眠。你能解释一下吗？可能与GTL有关吗？它在SDK实现中很深，我们很难调试。
4） 我们使用的是SDK 5.0.4-这可以让开发调试继续吗？
谢谢
保罗
嗨，梅勒，
1） 您所指的文档位于与SDK3相关的支持站点的已停止使用的文档中，显然，此体系结构在迁移到较新的SDK时已被放弃（据我所知，它未被使用）但新SDK的功能仍然存在，据我所知，您没有误解文档，而且很明显，即使在SDK 5上，您也可以进行这种配置，请为误解和我的仓促回答道歉。
2-3）CFG_DEVELOPMENT_DEBUG定义它所做的只是在fw运行时删除任何断言，并且在深度睡眠的情况下，它将关闭整个系统，我没有发现睡眠和该标志之间的任何关系。您能告诉我您是如何确定设备处于睡眠状态和唤醒状态的吗？我的意思是你是通过功率分析器测量，还是通过数字万用表测量？如果存在与RW堆栈或gtl接口相关的阻止设备进入睡眠的内容，则rwip_prevent_sleep_get（）应该会中断，但我仍然看不到这与CFG_DEVELOPMENT_DEBUG之间的任何关系（您是否看到睡眠和CFG_DEVELOPMENT_DEBUG之间的行为有任何变化）。检查这一点的一个方法是在函数底部的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_，然后作为gtl_exit_sleep（）的一部分再次调用flow_所致；但是，我无法通过跳转表进行调试。你能解释一下这里发生了什么，谁调用了这些跳转表函数，以及我如何调试它们吗？. 另外，我没有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 over SPI问题，是的，当设备唤醒时，它会在传输时发送一个重复流，据我所知，不会采取任何措施来修复该问题（请检查以确保），作为一种解决方法，您可以尝试添加一个计数器，以使字节流的发出次数不超过必要的次数，如下所示：
在spi_hci_flow_off_func（）中应用以下内容
if（0==流量
{
返回true;
}否则
{
flow_on_cnt——;
}
在spi_hci_flow_on_func（）中应用以下内容
如果（流量>0）
{
回来
}否则{
flow_on_cnt + +;
}
这不是一个经过验证或测试的解决方案，但您可以尝试它，以避免出现两个流on信号。
谢谢你的对话
感谢您修复的双流问题。这解决了我的一个问题。
另一个问题仍然存在。让我总结一下：
我们使用GTL和集成处理器（TASK_应用程序）。TASK_APP通过GTL向外部处理器发送消息，以执行高级应用程序特定任务。
我们已经配置了延长睡眠时间。
当我们启动时，DA不睡觉。它将进行广告宣传、连接并正常工作，但它不会睡眠。
如果我们从移动设备连接到它，并写入导致DA向MCU主机发送GTL消息的特征（控制点），则在发送该GTL消息后，DA立即开始正常睡眠。我们看到它为每个连接事件唤醒。如果我们断开手机的连接，我们会看到每次广告活动都会唤醒手机。它的工作原理和我们预期的一样，在事件之间睡觉。我们甚至可以让它在没有广告的情况下睡觉，并通过GPIO引脚上的外部唤醒事件唤醒它。
所以我们认为这个问题是由GTL消息和GTL状态引起的。我们没有显式地使用任何内核计时器。
在调试之后，我们在rwip.c中看到了它无法睡眠的两个原因。
如果（rwip\u prevent\u sleep\u 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消息后，设备会按其应有的方式运行。因此，我建议在设备未连接的情况下测试这种情况，例如，在设备配置完毕或设备创建数据库后，立即向外部MCU发送一条虚拟GTL消息。此外，设备上是否有任何外部唤醒配置，如果有，请删除该功能并检查是否会产生您正在经历的副作用？
谢谢你的对话
对你的建议进行试验后，我们找到了解决办法。我们向MCU发送了一个初始的READY消息，并接收回一个INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样直接进入睡眠(在2秒延迟之后)。如果在user_app_on_db_init_complete()期间发送READY消息，那么sleep仍然按照预期工作。因此，通过延迟READY消息，问题似乎得到了解决。
谢谢
保罗
嗨，梅勒，
谢谢你让我们知道，很高兴你能弄明白。
谢谢你的对话