我们在PAN1740模块上运行了一个应用程序。我们在DA14580上处理大多数消息，但我们有一个通过SPI连接到MCU的外部接口。通信使用GTL（即带有集成处理器应用程序的GTL接口）。
我们现在正试图让我们的工作应用程序在启用延长睡眠的情况下运行。我们有正确的东西，我相信。。。
#define cfg_gtl_spi.
#定义CFG_应用程序
#定义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_ging_to_sleep和.app_resume_from_leep打开和关闭GPIO线以指示睡眠，但我们没有看到这样的更改。
部分问题是我们无法调试主循环以理解它为什么不休眠，因为我们需要关闭调试。
如果我们让CFG_DEVELOPMENT_DEBUG#定义并调试主循环，我们*认为*我们看到它无法在rwip_prevent_sleep_get（）进入睡眠状态。
我们怀疑它是GTL的存在。这可能吗？我们如何让睡眠模式下工作？
谢谢,
保罗。
设备:
嗨pvmellor,
您必须选择您的设备是使用GTL（使用外部处理器）工作，还是具有应用程序级模块（启用APP_任务，独立配置）。你不能两者兼得，这是CFG_应用程序定义规定的。如果定义了CFG_应用程序，则您将处于集成处理器模式。如果未定义，则您将处于外部模式。
谢谢mt_dialog.
**你能给这条线定个轻重缓急吗**
更好的是，我们是否可以将讨论作为支持票离线，或者通过电话/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_APP(如图所示)来处理与概要文件相关的消息交换(create_db, enable/disable, write指示等)，再加上一个GTL接口，当一个特定的应用程序级事件发生时，GTL接口可以在较低频率的基础上与外部处理器交换高级消息。我们也支持dis和BASS配置文件(并可能在未来添加额外的配置文件)。
我们发现关于CFG_APP的文档令人困惑。config_basic.h文件中的注释说
/***************************************************************************************************************/
/ *集成或外部处理器配置* /
/*-定义的集成处理器模式。主机应用程序在DA14580处理器中运行。主机应用程序*/
/*是应用程序内核任务的任务*/
/* -undefined外部处理器模式。主机应用程序运行在外部处理器上。与* /
/ *通过GTL协议通过信令IFACE（UART，SPI等）* /
/***************************************************************************************************************/
然而，在上面提到的文件中，它说：
“如果未定义，它将启用*集成处理器应用程序*中的应用程序任务通过GTL/UART接口与外部处理器的通信。”
如能及时回复，将不胜感激。
保罗。
嗨pvmellor,
通常情况下，SDK的工作方式是推送到TASK_GTL或TASK_应用程序，我们没有任何项目同时使用两者，SDK在一个应用程序任务中报告，我查看了代码，显然两者都有可能（从未在实际领域进行过测试，我提到的只是一个理论）。因此，如果你正在做的是工作，我会假设你已经定义了CFG_应用程序，因此从堆栈到应用程序的每条消息最终都会到达TASK_应用程序，因此为了将其中一些消息发送到GTL任务，我假设你正在将TASK_应用程序的消息推回到堆栈，并将TASK_GTL作为接收器，这就是你在项目中所做的，因为这是我认为这会起作用的唯一方法？
关于睡眠，是GTL可以影响设备的睡眠，如果设备的发射尚未结束，并且仍有需要发送的待定数据，则设备将保持醒着，直到它们。关于调试和睡眠，如果您使用的是最新的SDK，则可以执行此操作。
谢谢mt_dialog.
谢谢你的回复。关于TASK_应用程序和TASK_GTL如何为我们工作，您的假设是正确的，只是我们发送给TASK_GTL的消息与我们作为TASK_应用程序接收的消息不同：它们是我们自己定义的更高级别的应用程序特定消息。与UM-B-017中描述的类似，并使用此处规定的方法。例如：MCU初始化绑定数据库（由外部MCU存储）、启动/停止不同类型的广告、输入当前电池电压水平（同样由MCU检测）、DA14580向MCU发送固件更新数据包以进行无线固件更新，等等。
当我们尝试睡眠时，没有gtl消息或在传输中。GTL消息不会特别频繁地发送 - 通常只是在启动时间，并且当存在正在进行的连接时，结束使用正在进行数据同步或固件更新。
大多数情况下，设备未处于连接状态，也未进行广告宣传。它只是在等待来自MCU的唤醒信号时处于休眠状态（该设备对运动敏感，并在运动时唤醒）。在其他时间，这是广告，睡眠是再次需要节省电力。
注意：我们正在使用Segger J-Link调试器对PAN1740ETU评估模块进行测试，并在我们自己的板上进行测试。
我们确实看到app_on_ble_powered()和app_on_system_powered()在广告时每376ms调用一次，在连接时每48.75ms调用一次。
那么，一些具体问题：
1） 如果我们的场景/体系结构很少且未经测试，那么为什么会有一份名为“集成处理器应用中的DA14580/581 GTL接口”的文档UM-B-017专门描述了它？我们是否误解了这份文件？它似乎正好代表了这个体系结构，并描述了如何使用它。亚博国际官网平台网址
2）由于没有地理位置或待处理的GTL活动，因为您可以帮助我们理解可能阻止设备睡觉的内容吗？这是我们现在回答最重要的问题。我们需要测试什么？我们可以做什么？
3） 如果我们让CFG_DEVELOPMENT_DEBUG#定义并调试主循环，我们认为它无法在rwip_prevent_sleep_get（）处进入睡眠。你能解释一下吗？可能与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\u prevent\u sleep\u get（）测试
b)通过(ble_intrawstat_get() & ble_grosstgtimmintrawstat_bit)测试内核计时器
c） 和上面一样-只是对内核计时器进行了第二次测试。
这三个测试被注释掉后，设备确实进入了长时间睡眠。我有它在376毫秒时为广告而睡觉和醒来的美好痕迹，当我连接时，我看到它在48毫秒时为连接事件而睡觉和醒来。如果我关闭广告，那么它将按照CFG_MAX_sleep_DURATION_PERIODIC_WAKEUP_MS计时器睡眠和醒来。我目前已经设置为600000（10分钟），工作正常（0.5秒的初始值为500）。
3)在每一个唤醒/休眠阶段，GTL接口都会重新启用。但有一个问题。每次发送两个流-on字节，然后在设备再次休眠时发送一个流-off字节。这导致了我的GTL协议代码在MCU -上的问题你能看一下这个问题是否可以解决吗？见附图。我怀疑这是由于直接通过跳转表调用flow_，然后作为gtl_exit_sleep（）的一部分再次调用flow_所致；但是，我无法通过跳转表进行调试。你能解释一下这里发生了什么，谁调用这些跳转表函数以及我如何调试它们吗?. 另外，我没有gtl.c的任何代码。这个有空吗？
4）如果我将恢复RWIP.c放回原始状态，那么如上所述，没有睡眠。但是，在发送第一个GTL消息后，睡眠开始正常工作。所以我认为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 over SPI问题，是的，当设备唤醒时，它会在传输时发送一个重复流，据我所知，不会采取任何措施来修复该问题（请检查以确保），作为一种解决方法，您可以尝试添加一个计数器，以使字节流的发出次数不超过必要的次数，如下所示：
在spi_hci_flow_off_func（）中应用以下内容
if（0 == flow_on_cnt）
{
返回true；
}别的
{
在碳纳米管上流动；
}
在spi_hci_flow_on_func（）中应用以下内容
如果(flow_on_cnt > 0)
{
返回;
其他}{
cnt++上的流；
}
这不是一个经过验证或测试的解决方案，但您可以尝试它，以避免出现两个流on信号。
谢谢mt_dialog.
感谢您对双流动问题的修复。这已经解决了我的一个问题。
另一个问题仍然存在。让我总结一下：
我们使用GTL和集成处理器（Task_App）。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_prevent_sleep_clear（rw_gtl_timeout）;
在我们的初始化代码中，这一行不再阻止我们睡觉。
第二个问题是
if（ble_intrawstat_get（）＆ble_grosstgtimintrawstat_bit）
休息;
设置ble_grosstgtimmintrawstat_bit位，防止休眠。我们没有太多关于这个位的数据，在代码中也没有明确设置它。我们已经尝试使用
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）;
在我们的初始化代码中，但这没有帮助-它正在其他地方设置。
您是否可以帮助更多有关此位的信息以及它在做什么以及它是如何设置的以及它如何与GTL接口相关。或者 - 更好的 - 你可以建议你对之前的问题做的修复吗？
谢谢,
保罗。
对话-在上面的问题上有帮助的机会吗?
它阻碍了我们的发展，我们没有太多的时间了！
非常感谢,，
保罗。
嗨pvmellor,
你提到的部分，设备停止是为了检查定时器设置，如果有定时器即将到期，设备将取消睡眠过程。由于在GTL层上进行消息交换时设备进入睡眠状态，您是否尝试在设备和主机之间交换假消息并检查这是否会迫使设备进入睡眠状态?
谢谢mt_dialog.
是的，这就是我们现在的工作方式。我们通过移动设备连接，然后手动发送一个假消息。然后启动设备休眠。
保罗
嗨pvmellor,
我的意思是，就我从上面的描述中所能理解的，由于某种原因，我无法确定，因为我无法在我的设置上进行复制，设备保持活动状态，显然，在您发送或接收GTL消息后，设备会按其应有的方式运行。因此，我建议在设备未连接的情况下测试这种情况，例如，在设备配置完毕或设备创建数据库后，立即向外部MCU发送一条虚拟GTL消息。此外，设备上是否有任何外部唤醒配置，如果有，请删除该功能并检查是否会产生您正在经历的副作用？
谢谢mt_dialog.
在试验了你的建议之后，我们找到了一个解决方案。我们向MCU发送了一条初始就绪消息，并收到了一条初始消息。但是，我们在user_app_init（）期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样立即进入睡眠状态（延迟2秒后）。如果我们在_db_init_complete（）上的用户_app_期间发送就绪消息，那么睡眠仍能按预期工作。因此，通过延迟就绪消息，问题似乎得到了解决。
谢谢,
保罗
嗨pvmellor,
谢谢你让我们知道，很高兴你能弄明白。
谢谢mt_dialog.