我们在PAN1740模块上运行了一个应用程序。我们在DA14580上处理大多数消息，但我们有一个通过SPI到MCU的外部接口。通信使用GTL(即集成处理器应用程序的GTL接口)。
我们现在正在尝试让我们的工作应用程序运行与延长睡眠启用。我相信我们有正确的定义…
#定义CFG_GTL_SPI
#定义CFG_APP
#定义CFG_INTEGRATED_HOST_GTL
#定义CFG_MEM_MAP_EXT_SLEEP
# undef CFG_MEM_MAP_DEEP_SLEEP
# undef CFG_DEVELOPMENT_DEBUG
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的存在。这可能吗？我们如何让睡眠模式工作？
谢谢,
保罗。
设备:
嗨pvmellor,
您必须选择您的设备是使用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_APP(如图所示)来处理与概要文件相关的消息交换(create_db, enable/disable, write指示等)，再加上一个GTL接口，当一个特定的应用程序级事件发生时，GTL接口可以在较低频率的基础上与外部处理器交换高级消息。我们也支持dis和BASS配置文件(并可能在未来添加额外的配置文件)。
我们发现关于CFG_APP的文档令人困惑。config_basic.h文件中的注释说
/***************************************************************************************************************/
/*集成或外部处理器配置*/
/* -defined集成处理器模式。主机应用程序运行在DA14580处理器上。主机应用程序* /
/*是TASK_APP内核任务。*／
/* -undefined外部处理器模式。主机应用程序运行在外部处理器上。与* /
/*通过GTL协议在信令iface（UART、SPi等）上的BLE应用*/
/***************************************************************************************************************/
但在上面提到的文件中，它说：
如果未定义，它将允许在“集成处理器应用程序”中与外部处理器的应用任务通过GTL/UART接口进行通信。
如能及时回复，将不胜感激。
保罗。
嗨pvmellor,
通常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评估模块进行测试，并且在我们自己的板上。
我们确实看到app_on_ble_powered()和app_on_system_powered()在广告时每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 -这可以留下开发调试吗?
谢谢,
保罗
嗨pvmellor,
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_grosstgtimmintrawstat_bit)测试内核计时器
c)与上面一样——但这是对内核计时器的第二次测试。
随着这三个测试的注释掉，设备确实进入了长时间的睡眠。当我连接时，我看到它在48毫秒的连接事件中睡着和醒着。如果我关闭广告，那么它将按照CFG_MAX_SLEEP_DURATION_PERIODIC_WAKEUP_MS定时器休眠和唤醒。我目前将这个设置为60万(10分钟)，工作正常(最初的值是500秒)。
3)在每一个唤醒/休眠阶段，GTL接口都会重新启用。但有一个问题。每次发送两个流-on字节，然后在设备再次休眠时发送一个流-off字节。这导致了我的GTL协议代码在MCU -上的问题你能不能帮我看看这个能不能修好?请看附呈的图。我怀疑这是由于flow_on被直接通过jump_table调用，然后可能作为gtl_exit_sleep()的一部分再次调用;但是，我不能调试到跳转表之前。你能解释一下这里发生了什么，谁调用这些跳转表函数以及我如何调试它们吗?．我也没有任何代码的gtl.c。这是可用的吗?
4） 如果我将restore rwip.c恢复到其原始状态，则如上所述，没有睡眠。但是，在发送第一条GTL消息后，睡眠开始正常工作。因此，我认为GTL在最初被认为处于错误状态时一定存在问题。这可能与上述问题的流程有关。你能不能看一看，看看这个是否可以改进，或者变通一下?
谢谢,
保罗
嗨pvmellor,
2 - 3) rwip_sleep()以上检查为了看看上面有一个等待的过程,如果它不会去睡觉,评论,这些条件都是不明智的或推荐的自设备将睡觉不管是否有事情要做。为了让设备进入睡眠状态，它会通过这些检查并做出决定。你是否看到设备总是坏掉，永远达不到程序核心深度睡眠，这将标志着睡眠期的开始?如果你提到设备正在取消睡眠由于在内核计时器，你能不能检查如果你从项目中删除计时器(如果你正在使用任何)(只是为了测试)会发生什么?另外，你可以移除GTL，并检查设备是否仍然具有相同的行为?尝试将您的应用程序作为独立设备使用，并验证设备进入睡眠模式。然后，您可以重新应用GTL配置，并检查GTL是否导致了睡眠问题。尝试查看是否有任何来自外部主机的等待命令或接口中保持设备唤醒的信号。
我能够使用ble_app_peripheral示例并在该项目上应用SPI GTL配置，然后我使用接近报告主机项目(另580上的host_proxr项目)作为完全嵌入/ GTL修改项目的主机，我没有发现任何问题，当应用程序从外部主机(从TASK_APP从完全托管的项目发送GTL消息到主机时，编写自定义特征)。
4)关于您报告的问题,这是一个已知的问题与GTL SPI是的它发送一个副本流在传输设备是醒来时,就我所知是没有采取行动,解决问题(可以肯定的是检查),你可以尝试作为一个工作周围将是添加一个计数器，以避免在字节上发出流超过必要的次数，如下所示:
在spi_hci_flow_off_func()中应用以下内容
if（0==流量
{
返回true;
}否则
{
flow_on_cnt——;
}
在spi_hci_flow_on_func（）中应用以下内容
如果(flow_on_cnt > 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_grosstgtimmintrawstat_bit位，防止休眠。我们没有太多关于这个位的数据，在代码中也没有明确设置它。我们已经尝试使用
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）；
在我们的初始化代码，但这没有帮助-它是在别处设置的。
您是否可以帮助了解更多关于该位的信息，它正在做什么，它是如何设置的，以及它与GTL接口的关系。或者，更好的是，您是否可以像对上一个问题一样提出修复建议？
谢谢,
保罗。
对话-在上面的问题上有帮助的机会吗?
这阻碍了我们的发展，我们没有多少时间了!
非常感谢,
保罗。
嗨pvmellor,
你提到的部分，设备停止是为了检查定时器设置，如果有定时器即将到期，设备将取消睡眠过程。由于在GTL层上进行消息交换时设备进入睡眠状态，您是否尝试在设备和主机之间交换假消息并检查这是否会迫使设备进入睡眠状态?
谢谢你的对话
是的，这就是我们现在的工作方式。我们通过移动设备连接，然后手动发送一个假消息。然后启动设备休眠。
保罗
嗨pvmellor,
我的意思是,只要我能理解从上面的描述中,由于某些原因,我不能确定,因为我不能够复制在我的设置,设备保持活跃,显然您发送或接收GTL消息后设备运行。所以我建议的是测试情况时，设备没有连接，例如发送一个假的GTL消息到外部MCU，一旦设备得到配置或一旦设备创建它的数据库。此外，设备上是否有任何外部唤醒配置，如果有，请删除该功能，并检查是否产生了您正在经历的副作用?
谢谢你的对话
对你的建议进行试验后，我们找到了解决办法。我们向MCU发送了一个初始的READY消息，并接收回一个INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样直接进入睡眠(在2秒延迟之后)。如果在user_app_on_db_init_complete()期间发送READY消息，那么sleep仍然按照预期工作。因此，通过延迟READY消息，问题似乎得到了解决。
谢谢,
保罗
嗨pvmellor,
谢谢你告诉我们，很高兴你弄明白了。
谢谢你的对话