我们有一个在Pan1740模块上运行的应用程序。我们在DA14580上处理大多数邮件，但我们确实在SPI上有一个外部接口到MCU。通信使用GTL（即GTL接口与集成处理器应用程序“）。
我们现在正在尝试使我们的工作应用程序运行，并启用扩展休眠状态。我们有正确的东西定义我相信......
#define cfg_gtl_spi.
#define cfg_app.
#定义CFG\u INTEGRATED\u HOST\u GTL
#定义CFG\u MEM\u MAP\u EXT\u SLEEP
#undef CFG\u MEM\u MAP\u DEEP\u睡眠
#undef CFG\开发\调试
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的存在。这可能吗？我们如何让睡眠模式下工作？
谢谢，
保罗。
设备：
嗨，梅勒，
您将不得不选择您的设备是否将使用GTL（使用外部处理器）或它将具有应用级模块（App_Task启用，独立配置）。您无法拥有两者，这就是CFG_App定义的决定。如果CFG_App定义，则如果未定义，则您将处于集成的处理器模式，然后您将处于外部模式。
谢谢mt_dialog.
**你能给这条线定个轻重缓急吗**
更好的是-我们可以把讨论作为支持票，或者打个电话/skype来讨论吗？
我们已经完成了我们的硬件设计和建设，并非常接近完成我们的固件开发。您的回答似乎表明我们有一个阻塞问题，可能需要我们交换到不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。
我们目前使用的架构非常类似于UM-B-017中所示的附图（jpg-in-zip），其标题为“集成处理器应用程序中的DA14580/581 GTL接口”。我们有一个集成处理器应用程序（即“任务应用程序”）和一个GTL接口，如文档所述。雷竞技安卓下载
唯一的差异是我们使用SPI进行外部通信，而不是UART，我们不使用显式唤醒GPIO（我们为此目的使用Dreadey）。
你能确认一下吗：你是说在你之前的回复中，在集成处理器应用程序中使用GTL接口是不可能的吗？不支持上述体系结构？或者我们误解了这份文件及其含义？
我们使用该文件第5节中所述的传输格式，我们在App.h中定义了我们自己的一组应用程序级别消息和处理程序，如第6节所定义。第7节讨论了GTL在使用中的最大睡眠期间，但我们有尚未达到这一点。我们的代码稳定，一直运行良好，一段时间通过GTL消息传递给我们的外部MCU。但是，我们的申请不会进入（延长）睡眠。
如果所附图表中的体系结构受支持，您能否帮助我们理解为实现所描述的体系结构，我们需要做哪些更改？我们需要一个任务应用程序（如图所示）来处理与概要文件相关的消息交换（创建\u db、启用/禁用、写入指示等），另外还需要一个GTL接口，以便在特定应用程序级事件发生时以较低的频率与外部处理器交换高级消息。我们还支持DISS和BASS配置文件（将来可能会添加其他配置文件）。
我们发现有关CFG\u应用程序的文档令人困惑。config_basic.h文件中的注释是
/ *************************************************************************************************************** /
/ *集成或外部处理器配置* /
/ * - 定义集成处理器模式。主机应用程序在DA14580处理器中运行。主机申请* /
/*是应用程序内核任务的任务*/
/*-未定义的外部处理器模式。主机应用程序在外部处理器上运行。与…沟通*/
/ *通过GTL协议通过信令IFACE（UART，SPI等）* /
/ *************************************************************************************************************** /
然而，在上面提到的文件中，它说：
“如果未定义，它将启用*集成处理器应用程序*中应用程序任务的GTL/UART接口与外部处理器的通信。”
如能及时答复，将不胜感激。
保罗。
嗨，梅勒，
通常情况下，SDK如何推动Task_GTL或Task_App，我们没有任何使用的项目，SDK报告在一个应用程序任务中，我看看代码，显然它可能是合理的两者（从未在实际领域测试过，我提到的只是一个理论）。所以如果你正在做的是工作我会想你有一个定义的cfg_app，所以从堆栈到应用程序的每条消息都将结束tase_app，所以为了让一些这些消息给gtl任务我认为你正在将消息从Task_App返回到堆栈中，并将Task_GTL作为接收器，因此您在项目中正在做的是什么，因为这是我认为这将工作的唯一方法？
关于睡眠，是GTL可以影响设备的睡眠，如果设备的发射尚未结束，并且仍有需要发送的待定数据，则设备将保持醒着，直到它们。关于调试和睡眠，如果您使用的是最新的SDK，则可以执行此操作。
谢谢mt_dialog.
谢谢你的回复。关于任务应用程序和任务GTL如何为我们工作，您的假设是正确的，只是我们发送给任务GTL的消息与我们作为任务应用程序收到的消息不同：它们是我们自己定义的更高级别的特定于应用程序的消息。与UM-B-017中描述的方法类似，并使用此处规定的方法。例如：MCU初始化绑定数据库（由外部MCU存储）、启动/停止不同类型的广告、输入当前电池电压水平（MCU也会检测到这一点）、DA14580向MCU发送固件更新包以进行无线固件更新，等等。
当我们尝试睡眠时，没有gtl消息或在传输中。GTL消息不会特别频繁地发送 - 通常只是在启动时间，并且当存在正在进行的连接时，结束使用正在进行数据同步或固件更新。
大部分时间设备都不处于连接状态，也不是广告。它将简单地睡着了等待来自MCU的唤醒信号（设备是运动敏感并在运动上唤醒）。在其他时候，它是广告和睡眠再次需要节省力量。
注意我们正在使用Segger J-Link调试器进行PAN1740ETU评估模块进行测试，并在我们自己的电路板上。
我们确实看到，在发布广告时，每隔376ms，在连接时每隔48.75ms，就会有人调用\u ble\u powered（）上的app\u和\u system\u powered（）上的app\u。
然后是一些具体问题：
1）如果我们的方案/架构是罕见和未经测试的，那么如何出现文件UM-B-017，其题为“集成处理器应用程序中的DA14580 / 581 GTL接口”，具体描述它？雷竞技安卓下载我们误解了这份文件吗？它似乎代表了这种架构，并描述了如何使用它。
2）由于没有地理位置或待处理的GTL活动，因为您可以帮助我们理解可能阻止设备睡觉的内容吗？这是我们现在回答最重要的问题。我们需要测试什么？我们可以做什么？
3） 如果我们让CFG#DEVELOPMENT#DEBUG#定义并调试主循环，我们会认为它无法在rwipŠpreventŠsleepŠget（）进入sleep。你能解释一下吗？可能与GTL有关吗？它在SDK实现中很深，我们很难调试。
4） 我们使用的是sdk5.0.4-这可以让开发调试继续吗？
谢谢，
保罗
嗨，梅勒，
1）您所指的文档位于与SDK3相关的支持站点的已停止文档中，显然这种架构在移动到较新的SDK时被贬低（据我所知，它没有使用）但是，函数仍然是新的SDK，据我所知，我可以告诉你没有误解这些文件，显然你也可以在SDK 5上有这种配置，但对此误解和我的仓促答案道歉。
2-3）CFG_DEVELIMMENT_DEBUG定义所做的一切都是在运行FW运行时删除任何断言，并且在深度睡眠的情况下，它将关闭整个SYSRAM，我没有在睡眠之间找到任何关系和该国旗之间的任何关系。你能告诉我你究竟确定设备睡眠的究竟是多么确定？我的意思是你通过电力分布器测量这一点，或者您通过DMM测量？RWIP_Prevent_sleep_get（）应在休息中恢复与RW堆栈或GTL接口相关的东西进行打破，但我仍然没有看到任何关系，并且您看到了CFG_development_debug（您是否看到行为的任何变化在睡眠和cfg_development_debug之间）。一个想法要检查这一点是在函数底部的RWIP_SLEEP（）函数中放置一个刹车点，在该函数底部决定在检查正确的条件后确实可以睡眠，如果您打击该断点然后该设备将睡觉。
4）SDK5.0.4是唯一能够在睡眠模式下使用调试操作的SDK。
谢谢mt_dialog.
根据你的建议，我已经把CFG\u DEVELOPMENT\u DEBUG放上去调试了睡眠代码/问题。
1） 为了检测睡眠，我使用了在.app\u going\u To \u sleep和.app\u resume\u from \u sleep上设置的回调来打开和关闭GPIO线以指示睡眠。仔细检查后发现，这些函数都经过了编译器的优化。在调用这些函数时，外围设备似乎已关闭，因此编译器删除了代码（令人惊讶）。我移动了代码来切换GPIO行，刚好在外设被禁用之前，这个方法用于指示睡眠。
2）Rwip_sleep（）中有三个地方，防止它睡觉。
a）RWIP_PREVENT_SLEEP_GET的测试（）
b） 内核计时器的测试，通过（ble\u intrawstat\u get（）&ble\u GROSSTGTIMINTRAWSTAT\u BIT）
c）与上述相同 - 但是内核定时器的第二次测试。
使用这三个测试注释出来，设备确实进入了睡眠状态。我有漂亮的痕迹，睡觉和醒来，为376毫秒广告，当我连接时，我看到它睡觉并在48ms中醒来以进行连接事件。如果我转过来，那么它将根据CFG_MAX_SLEEP_DOURATION_PERIODIC_WAKEUP_MS计时器睡眠和唤醒。我目前拥有高达600,000（十分钟），工作正常（原始值为500秒，0.5秒）。
3） 在每个唤醒/休眠期间，GTL接口再次启用。但有一个问题。每次发送两个flow-on字节，然后在设备再次休眠时发送flow-off。这会导致MCU上的GTL协议代码出现问题-您是否能够了解这是否可以修复？见附图。我怀疑这是由于flow_on直接通过jump_表调用，然后作为gtl_exit_sleep（）的一部分再次调用；但是，我无法调试回跳转表。你能解释一下这里发生了什么，谁调用了这些跳转表函数，以及我如何调试它们吗？. 我也没有任何代码为gtl.c。这有空吗？
4）如果我将恢复RWIP.c放回原始状态，那么如上所述，没有睡眠。但是，在发送第一个GTL消息后，睡眠开始正常工作。所以我认为GTL必须有一个问题最初被认为是错误的状态。也许这与上面的Flow_on问题有关。你可以看看，看看这是否可以改进，或者遍布它？
谢谢，
保罗
嗨，梅勒，
2-3）rwip_sleep（）进行了上述所有检查，以查看上面的任何一项是否有挂起的过程，如果有，则不会进入睡眠状态，注释掉这些条件是不明智的，也不建议这样做，因为无论是否有事情要做，设备都将进入睡眠状态。为了让设备进入睡眠状态，它会通过这些检查并做出决定。你看到了吗，设备总是中断，从来没有达到程序核心深度睡眠，将信号的睡眠期乞讨？如果您提到设备由于内核中的计时器而取消睡眠，您能检查一下如果您从项目中删除计时器（如果您正在使用任何计时器）（只是为了测试）会发生什么吗？另外，您是否可以卸下GTL并检查设备是否仍具有相同的行为？只需尝试将应用程序用作独立设备，并验证该设备是否进入睡眠模式。然后您可以重新应用GTL配置，并检查GTL是否导致睡眠问题。尝试查看是否有任何来自外部主机的挂起命令或接口中保持设备唤醒的信号。
我能够使用ble\u app\u peripheral示例并在该项目上应用SPI GTL配置，然后我使用了邻近报告器主机项目（另一个580上的host\u proxr项目）作为完全嵌入/GTL修改项目的主机，当应用程序从外部主机启动时，我在睡眠中找不到任何问题（在编写自定义特征时，从完全托管的项目向主机发送来自任务应用程序的GTL消息）。
4） 关于您报告的问题，这是一个已知的问题，GTL over SPI，是的，当设备唤醒时，它会在传输时发送一个复制流，据我所知，将不会有任何操作来修复该问题（检查以确保），作为一种解决方法，您可以尝试添加一个计数器，以便在字节上发出流的次数不超过必要的次数，如下所示：
在spi_hci_flow_off_func（）中应用以下内容
if（0 == flow_on_cnt）
{
返回真;
}别的
{
flow_on_cnt--;
}
在spi_hci_flow_on_func（）中应用以下内容
如果（流量>0）
{
返回;
}其他{
flow_on_cnt ++;
}
这不是一个经过验证或测试的解决方案，但它是您可以尝试的，以避免出现两个流信号。
谢谢mt_dialog.
感谢您对双流动问题的修复。这已经解决了我的一个问题。
其他问题仍然存在。让我总结：
我们使用GTL和集成处理器（Task_App）。Task_App通过GTL向外部处理器发送消息以执行高级应用程序特定任务。
我们已经配置了延长睡眠时间。
当我们启动da不睡觉时。它将正确宣传和连接和运行，但它不会睡觉。
如果我们从移动设备连接到它，并写入特征（控制点），导致DA到MCU主机发送GTL消息，那么在发送此GTL消息后立即将DA开始睡眠这应该。我们看到每个连接事件唤醒。如果我们断开我们的手机，我们会看到每个广告活动的唤醒。它适用于我们期望的，在活动之间睡觉。我们甚至可以将其放置如此睡眠，没有广告，并通过GPIO引脚上的外部唤醒活动唤醒。
所以我们认为这个问题是由于GTL消息和GTL状态。我们没有明确使用任何内核定时器。
在调试之后，我们在rwip.c中看到了两个它无法休眠的原因。
if（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\ U GROSSTGTIMINTRAWSTAT\位已设置并防止睡眠。我们没有太多关于这个位的数据，代码中也没有显式地设置它。我们试过使用
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）;
在我们的初始化代码中，但这并没有帮助 - 它正在其他地方设置。
您是否可以帮助更多有关此位的信息以及它在做什么以及它是如何设置的以及它如何与GTL接口相关。或者 - 更好的 - 你可以建议你对之前的问题做的修复吗？
谢谢，
保罗。
对上述问题有帮助吗？
它正在举起我们的发展，我们没有很多时间剩下！
非常感谢，
保罗。
嗨，梅勒，
您提到的设备停止部分是为了检查已设置的计时器，如果计时器即将过期，则设备将取消睡眠过程。由于在GTL层上进行消息交换时设备进入睡眠状态，因此您是否尝试在设备和主机之间交换虚拟消息，并检查这是否会迫使设备进入睡眠状态？
谢谢mt_dialog.
是的，这就是我们现在的工作方式。我们通过移动设备连接到设备，然后手动发送一条假消息。这将启动设备正常睡眠。
保罗
嗨，梅勒，
我的意思是，据我所知，从上面的描述，由于某种原因，我无法确定，因为我无法复制我的设置，该设备保持活跃，显然在您发送或接收GTL消息后，该设备运行正常。因此，我建议的是在设备未连接的情况下测试这种情况，例如，一旦设备得到配置，或者一旦设备创建了数据库，就向外部MCU发送一个虚拟GTL消息。另外，设备上是否有任何外部唤醒配置，如果有，请删除该功能并检查是否会产生您正在经历的副作用？
谢谢mt_dialog.
在尝试完成您的建议之后，我们发现了一个解决方案。我们正在向MCU发送初始准备消息，并接收init消息。但是，我们在user_app_init（）期间发送了就绪消息，这导致了问题。如果我们根本没有发送就绪消息，那么DA直接睡觉（在我们预期的2秒延迟之后）。如果我们在user_app_on_db_init_complete（）期间发送就绪消息，那么睡眠仍然按预期工作。因此，通过延迟就绪的消息，问题似乎已经解决。
谢谢，
保罗
嗨，梅勒，
谢谢你让我们知道，很高兴你能弄明白。
谢谢mt_dialog.