我们在PAN1740模块上运行了一个应用程序。我们在DA14580上处理大多数消息，但我们有一个通过SPI连接到MCU的外部接口。通信使用GTL（即带有集成处理器应用程序的GTL接口）。
我们现在正试图让我们的工作应用程序在启用延长睡眠的情况下运行。我们有正确的东西，我相信。。。
#定义CFG_GTL_SPI
#定义CFG_应用程序
#定义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_任务，独立配置）。你不能两者兼得，这是CFG_应用程序定义规定的。如果定义了CFG_应用程序，则您将处于集成处理器模式。如果未定义，则您将处于外部模式。
谢谢你的对话
**请您优先处理这个线程**
更好的是，我们可以把讨论离线作为支持票，还是通过电话/skype来讨论?
我们已经完成了硬件设计和构建，并且非常接近完成固件开发。您的回答似乎表明我们有一个阻塞问题，可能需要我们切换到不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。
我们目前使用的架构与UM-B-017中所附的图表(jpg格式zip)非常相似，标题为“集成处理器应用中的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文件中的注释是
/***************************************************************************************************************/
/*集成或外部处理器配置*/
/*-定义的集成处理器模式。主机应用程序在DA14580处理器中运行。主机应用程序*/
/*是TASK_APP内核任务。*／
/*-未定义的外部处理器模式。主机应用程序在外部处理器上运行。与*/
/*通过GTL协议在信令iface（UART、SPi等）上的BLE应用*/
/***************************************************************************************************************/
但在上面提到的文件中，它说：
如果未定义，它将允许在“集成处理器应用程序”中与外部处理器的应用任务通过GTL/UART接口进行通信。
如能及时答复，将不胜感激。
保罗。
嗨，梅勒，
通常情况下，SDK的工作方式是推送到TASK_GTL或TASK_应用程序，我们没有任何项目同时使用两者，SDK在一个应用程序任务中报告，我查看了代码，显然两者都有可能（从未在实际领域进行过测试，我提到的只是一个理论）。因此，如果你正在做的是工作，我会假设你已经定义了CFG_应用程序，因此从堆栈到应用程序的每条消息最终都会到达TASK_应用程序，因此为了将其中一些消息发送到GTL任务，我假设你正在将TASK_应用程序的消息推回到堆栈，并将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） 如果我们的场景/体系结构很少且未经测试，那么为什么会有一份名为“集成处理器应用中的DA14580/581 GTL接口”的文档UM-B-017专门描述了它？我们是否误解了这份文件？它似乎正好代表了这个体系结构，并描述了如何使用它。亚博国际官网平台网址
2） 由于没有GTL活动，您能否帮助我们了解什么可能会阻止设备睡眠？这是我们现在要回答的最重要的问题。我们需要测试什么？我们能做什么？
3)如果我们定义CFG_DEVELOPMENT_DEBUG #并调试主循环，我们认为我们看到它在rwip_prevent_sleep_get()中没有进入sleep。你能解释一下吗?会和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\u prevent\u sleep\u get（）测试
b） 通过（ble_intrawstat_get（）&ble_GROSSTGTIMINTRAWSTAT_BIT）测试内核计时器
c） 和上面一样-只是对内核计时器进行了第二次测试。
这三个测试被注释掉后，设备确实进入了长时间睡眠。我有它在376毫秒时为广告而睡觉和醒来的美好痕迹，当我连接时，我看到它在48毫秒时为连接事件而睡觉和醒来。如果我关闭广告，那么它将按照CFG_MAX_sleep_DURATION_PERIODIC_WAKEUP_MS计时器睡眠和醒来。我目前已经设置为600000（10分钟），工作正常（0.5秒的初始值为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；
}否则
{
在碳纳米管上流动；
}
在spi_hci_flow_on_func（）中应用以下内容
如果（流量>0）
{
回来
}否则{
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发送了一条初始就绪消息，并收到了一条初始消息。但是，我们在user_app_init（）期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样立即进入睡眠状态（延迟2秒后）。如果我们在_db_init_complete（）上的用户_app_期间发送就绪消息，那么睡眠仍能按预期工作。因此，通过延迟就绪消息，问题似乎得到了解决。
谢谢
保罗
嗨，梅勒，
谢谢你告诉我们，很高兴你弄明白了。
谢谢你的对话