我们在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_state_t app_default_sleep_mode = ARCH_EXT_SLEEP_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，那么您将处于集成处理器模式;如果未定义，那么您将处于外部模式。
由于MT_dialog
**请您优先处理这个线程**
更好的是，我们是否可以将讨论作为支持票离线，或者通过电话/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，这应该是可能的。
由于MT_dialog
谢谢你的回复。你对TASK_APP和TASK_GTL如何为我们工作的假设是正确的，除了我们发送给TASK_GTL的消息与我们接收到的TASK_APP不同:它们是我们自己定义的更高级别的特定于应用程序的消息。与UM-B-017中描述的类似，并使用那里设置的方法。例如:单片机的初始化连接数据库(由外部单片机存储),启动/停止不同类型的广告,把当前的电池电压水平(这是由单片机感觉到),和DA14580将固件更新数据包发送到单片机无线固件更新,等等。
当我们试图休眠时，没有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相关的支持站点的已停止使用的文档中，显然，此体系结构在迁移到较新的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。
由于MT_dialog
按照您的建议，我已经打开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消息被发送之后，sleep开始正常工作。所以我认为GTL一开始就被认为处于错误的状态是有问题的。也许这与上面的flow_on问题有关。你能不能看一看，看看这个是否可以改进，或者变通一下?
谢谢,
保罗
嗨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 == flow_on_cnt) / /输出
｛
返回true;
其他}
｛
flow_on_cnt——;
｝
在spi_hci_flow_on_func()中应用以下内容
如果(flow_on_cnt > 0)
｛
返回;
其他}{
flow_on_cnt + +;
｝
这不是一个经过验证或测试的解决方案，但您可以尝试这样做，以避免在信号上有两个流。
由于MT_dialog
感谢您修复了双流动问题。这解决了我的一个问题。
另一个问题仍然存在。让我来总结:
我们使用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_grosstgtimmintrawstat_bit位，防止休眠。我们没有太多关于这个位的数据，在代码中也没有明确设置它。我们已经尝试使用
REG_BLE_WR (BLE_INTRAWSTAT_ADDR BLE_INTRAWSTAT_RESET);
在我们的初始化代码中，但这没有帮助-它正在其他地方设置。
您能否提供更多关于这个位的信息，它在做什么，它是如何设置的，以及它可能如何与GTL接口相关。或者——更好的是——你能像之前的问题一样提出一个解决方案吗?
谢谢,
保罗。
对话-在上面的问题上有帮助的机会吗?
这阻碍了我们的发展，我们没有多少时间了!
非常感谢,
保罗。
嗨pvmellor,
你提到的部分，设备停止是为了检查定时器设置，如果有定时器即将到期，设备将取消睡眠过程。由于在GTL层上进行消息交换时设备进入睡眠状态，您是否尝试在设备和主机之间交换假消息并检查这是否会迫使设备进入睡眠状态?
由于MT_dialog
是的，这就是我们现在的工作方式。我们通过移动设备连接，然后手动发送一个假消息。然后启动设备休眠。
保罗
嗨pvmellor,
我的意思是,只要我能理解从上面的描述中,由于某些原因,我不能确定,因为我不能够复制在我的设置,设备保持活跃,显然您发送或接收GTL消息后设备运行。所以我建议的是测试情况时，设备没有连接，例如发送一个假的GTL消息到外部MCU，一旦设备得到配置或一旦设备创建它的数据库。此外，设备上是否有任何外部唤醒配置，如果有，请删除该功能，并检查是否产生了您正在经历的副作用?
由于MT_dialog
对你的建议进行试验后，我们找到了解决办法。我们向MCU发送了一个初始的READY消息，并接收回一个INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样直接进入睡眠(在2秒延迟之后)。如果在user_app_on_db_init_complete()期间发送READY消息，那么sleep仍然按照预期工作。因此，通过延迟READY消息，问题似乎得到了解决。
谢谢,
保罗
嗨pvmellor,
谢谢你告诉我们，很高兴你弄明白了。
由于MT_dialog