我们有一个应用程序运行在PAN1740模块上。我们在DA14580上处理大多数消息，但是我们有一个通过SPI到MCU的外部接口。通信使用GTL(即集成处理器应用程序的GTL接口)。
我们现在正尝试让我们的工作应用程序运行时启用延长睡眠。我相信我们有正确的东西定义…
#define cfg_gtl_spi.
#定义CFG_APP
#define cfg_integrated_host_gtl.
#define 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_DEVELVELMMENT_DEBUG #DEFINED并调试主循环我们认为*我们会看到它无法在RWIP_PREVENT_SLEEP_GET（）以睡眠进入睡眠状态。
我们怀疑它是GTL的存在。这可能吗？我们如何让睡眠模式下工作？
谢谢，
保罗。
设备：
嗨pvmellor，
您必须选择您的设备是使用GTL(使用外部处理器)工作，还是使用一个应用程序级模块(启用APP_TASK，独立配置)。您不能同时拥有两者，这是CFG_APP定义所规定的。如果定义了CFG_APP，那么您将处于集成处理器模式，如果它未定义，那么您将处于外部模式。
谢谢mt_dialog.
**你能优先考虑这个线程**
更好仍然 - 我们可以将讨论摘录作为支持机票还是呼叫/ Skype讨论？
我们已完成硬件设计和构建，并非常接近完成我们的固件开发。您的回复似乎表明我们有一个阻塞问题，这可能需要我们交换给不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。
我们目前正在使用与附件（JPG中的JPG）非常相似的架构，如UM-B-017所示，其中题为“集成处理器应用程序中的DA14580 / 581 GTL接口”。雷竞技安卓下载我们有一个集成的处理器应用程序（即“任务应用程序”）和GTL接口，因为文档描述。
唯一的区别是，我们使用SPI进行外部通信，而不是UART，并且我们不使用显式的Wakeup GPIO(为此目的我们使用DREADY)。
您能否确认：您是否在您以前的回复中说明，这是不可能在集成的处理器应用程序中使用GTL接口吗？上面的架构不受支持吗？或者也许我们误解了这份文件及其含义？
我们使用文档第5节中描述的传输格式，我们在app.h中定义自己的应用程序级消息集和处理程序，如第6节中定义的。第7节讨论了使用GTL时的最大睡眠时间，但是我们还没有讲到这一点。我们的代码是稳定的，并且已经运行了一段时间，将GTL消息传递给我们的外部MCU。但是，我们的应用程序不会进入(扩展的)睡眠状态。
如果支持附加图中的架构，请您可以帮助我们了解我们所需要的更改需要更改以进行更改吗？我们需要一个task_app（如图所示）来处理配置文件相关的消息交换（Create_DB，启用/禁用，写入指示等），以及GTL接口，以在较少频繁的基础上使用外部处理器交换高级消息发生特定的应用程序级事件。我们还支持播放和低音配置文件（并且可以在未来添加其他人）。
我们发现CFG_APP围绕混淆的文档。config_basic.h文件中的注释说
/***************************************************************************************************************/
/ *集成或外部处理器配置* /
/*定义集成处理器模式。主机应用程序运行在DA14580处理器中。主机应用程序* /
/ *是task_app内核任务。* /
/ * - 义外部处理器模式。主机应用程序在外部处理器上运行。与* /沟通沟通
/ *通过GTL协议通过信令IFACE（UART，SPI等）* /
/***************************************************************************************************************/
然而，在上面提到的文件中，它说：
“如果未定义，它将在*集成处理器应用程序*中使用外部处理器的应用程序任务的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中描述的那些，并使用那里的方法。例如：对于MCU初始化绑定数据库（由外部MCU存储），以启动/停止不同类型的广告，以将电流电池电压电平（再次由MCU感测），以及DA14580将固件更新报文发送到MCU以获取空中固件更新等。
当我们尝试睡眠时，没有gtl消息或在传输中。GTL消息不会特别频繁地发送 - 通常只是在启动时间，并且当存在正在进行的连接时，结束使用正在进行数据同步或固件更新。
大多数时候，设备并没有处于连接状态，也没有发布广告。它将只是休眠，等待来自单片机的唤醒信号(该设备是运动敏感的，并在运动中醒来)。在其他时间，它是广告和睡眠再次需要保存电力。
注意，我们正在PAN1740ETU评估模块与Segger J-Link调试器进行测试，并在我们自己的板上。
我们在广告时每376毫秒查看App_on_ble_powered（）和app_on_system_powered（）调用的调用，并在连接时每48.75ms调用。
一些具体的问题:
1)如果我们的方案/架构是罕见的和未经测试的，为什么会有一个文档UM-B-017，它的标题是“DA14580/581集成处理器应用中的GTL接口”，具体描述它?雷竞技安卓下载我们误解了这个文件吗?它似乎准确地代表了这个体系结构，并描述了如何使用它。
2）由于没有地理位置或待处理的GTL活动，因为您可以帮助我们理解可能阻止设备睡觉的内容吗？这是我们现在回答最重要的问题。我们需要测试什么？我们可以做什么？
3）如果我们留下CFG_DEVELVELPMENT_DEBUG #defined并调试主循环，我们认为我们会看到它无法在RWIP_PREVENT_SLEEP_GET（）中输入睡眠状态。你能解释一下吗？它可以与gtl相关吗？它在SDK实现中深入了解，我们难以调试。
4）我们使用的是SDK 5.0.4 - 这是可以留下开发调试的吗？
谢谢，
保罗
嗨pvmellor，
1)文档,你参照位于停止相关的文档的支持网站SDK3,显然这种架构是abandonded当搬到一个新的SDK(这不是用作据我所知)但是functionallity仍然在新的SDK,据我所知，你没有误解的文件，显然你可以有这种配置，甚至在SDK 5，抱歉的误解和我仓促的回答。
2-3) CFG_DEVELOPMENT_DEBUG定义所做的就是在fw运行时删除任何断言，在深度睡眠的情况下，它会关闭整个syram，我没有发现睡眠和那个标志之间的任何关系。你能告诉我你是如何确定设备处于休眠状态和唤醒状态的吗?我的意思是你是通过功率分析器来测量，还是通过数字多用表来测量?rwip_prevent_sleep_get()应该去休息,如果有一些防止设备睡觉这与RW堆栈或gtl接口但仍然我不看到任何关系berween和CFG_DEVELOPMENT_DEBUG(你看到任何改变在睡眠和CFG_DEVELOPMENT_DEBUG)之间的行为。一个想法来检查这是地方的brakepoint rwip_sleep底部()函数的函数,它是决定设备确实是要适量后睡眠条件检查,如果你遇到断点的设备是睡觉。
4）SDK5.0.4是唯一能够在睡眠模式下使用调试操作的SDK。
谢谢mt_dialog.
根据您的建议，我已经将CFG_Development_debug放在上面并调试睡眠代码/问题。
1）检测睡眠我使用的回调设置在.app_ging_to_sleep和.app_resume_from_sleep打开和关闭以指示睡眠状态以切换GPIO线。仔细检查显示这些功能由编译器优化的功能。似乎外围设备在调用这些功能时关闭，因此代码由编译器（令人惊讶）删除。我移动了代码将GPIO行切换到禁用外设之前，此方法工作以指示睡眠。
2) rwip_sleep()中有三个地方阻止了它睡觉。
测试rwip_prevent_sleep_get()
b）通过（ble_intrawstat_get（）和ble_grosstgtimintrawstat_bit的内核定时器测试
c)和上面一样，只是内核定时器的第二次测试。
这三个测试被注释掉后，该设备确实进入了长时间睡眠状态。当我连接时，我看到它在48毫秒的连接事件中睡着和醒来。如果我关闭广告，那么它将按照CFG_MAX_SLEEP_DURATION_PERIODIC_WAKEUP_MS计时器休眠和唤醒。我目前将其设置为600,000(10分钟)，并且运行良好(初始值为500，持续0.5秒)。
3）在每个唤醒/睡眠期间，再次启用GTL接口。但有一个问题。每次发送两个流字节，然后在设备再次休眠时，然后流关闭。这会导致MCU上的GTL协议代码出现问题 -你能去看看这个是否可以修复吗?请参阅附图。我怀疑是由于Flow_on直接通过Jump_Table调用，然后可能再次调用GTL_EXIT_SLEEP（）的一部分;但是，我无法通过跳转表调试。你能解释这里正在发生的事情，谁叫这些跳跃表函数以及如何调试它们？。此外，我没有任何代码gtl.c.这是可用的吗？
4）如果我将恢复RWIP.c放回原始状态，那么如上所述，没有睡眠。但是，在发送第一个GTL消息后，睡眠开始正常工作。所以我认为GTL必须有一个问题最初被认为是错误的状态。也许这与上面的Flow_on问题有关。你能看看这个是否可以改进，或者解决吗?
谢谢，
保罗
嗨pvmellor，
2-3）RWIP_SLEEP（）拥有上述所有检查，以了解上述内容的任何内容是否具有挂起的过程，如果它不会睡觉，请评论这些条件不会明智或推荐，因为设备将如果有什么可做的事情，无论如何都要睡觉。为了让设备睡眠，通过这些检查并决定。您是否看到设备始终会破坏，从未达到程序核心深度睡眠，这将发出睡眠期的乞讨？如果您提到由于内核定时器导致设备取消睡眠，如果您从项目中删除定时器（如果您使用的是任何），请查看会发生什么（如果是用于测试）？还可以请删除GTL并检查设备是否存在相同的行为？只需尝试将应用程序用作独立设备，并验证设备进入睡眠模式。然后，您可以重新应用GTL配置并检查GTL是否导致睡眠问题。尝试查看外部主机的任何挂起命令或接口中的信号，使设备唤醒。
我能够使用BLE_APP_PERITIELAL示例并在该项目上应用SPI GTL配置，然后我使用了Proximity Reporter主机项目（另一个580上的Host_proxr项目），以充分嵌入式/ GTL修改项目充当主机，我可以在外部主机的应用程序中找到睡眠中的任何问题（在编写自定义特征时从Task_App从Task_App从Task_App发送GTL消息）。
4）关于您报告的问题，这是一个已知的问题，具有SPI的GTL，是的，当设备正在唤醒时，它会在传输时发出复制流，并且据我所知，即我知道将没有任何动作要修复问题（检查以确定为确定），您可以尝试作为一个工作，以便添加计数器，以便在字节上发出比未来的更多次数，如下所示：
在spi_hci_flow_off_func（）中应用以下内容
if（0 == flow_on_cnt）
{
返回true;
}别的
{
flow_on_cnt——;
}
在spi_hci_flow_on_func（）中应用以下内容
if（flow_on_cnt> 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_prevent_sleep_get（）！= 0）
休息;
这条线可以进一步防止它（即休息执行）。这是因为rwip_prevent_sleep_get（）返回rw_gtl_timeout。所以我们使用
rwip_prevent_sleep_clear（rw_gtl_timeout）;
在我们的初始化代码中，这一行不再阻止我们睡觉。
第二个问题是
if（ble_intrawstat_get（）＆ble_grosstgtimintrawstat_bit）
休息;
BLE_GROSSTGTIMINTRAWSTAT_BIT位设置并防止睡眠。我们没有多少数据关于该位，并且在代码中没有明确设置任何地方。我们尝试过
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）;
在我们的初始化代码中，但这没有帮助-它被设置在其他地方。
您是否可以帮助更多有关此位的信息以及它在做什么以及它是如何设置的以及它如何与GTL接口相关。或者 - 更好的 - 你可以建议你对之前的问题做的修复吗？
谢谢，
保罗。
对话框 - 上述问题的任何帮助？
它阻碍了我们的发展，我们没有多少时间了!
非常感谢，
保罗。
嗨pvmellor，
您提到设备停止的部分用于检查设置的定时器，如果有时间即将到期的计时器，则设备将取消休眠过程。由于设备在GTL图层上交换时，设备会睡眠，因此您是否尝试在设备和主机之间交换伪消息，并检查它是否会强制设备睡觉？
谢谢mt_dialog.
是的 - 这就是我们现在的工作方式。我们通过移动设备连接到设备，然后手动导致要发送的虚拟消息。然后，这将开始睡觉的设备。
保罗
嗨pvmellor，
我的意思是，就我可以从上面的描述中理解，因为某种原因我无法确定自从我无法在我的设置上复制，因此在发送或接收GTL后，设备将处于活动状态且显然是显而易见的消息设备应按原样进行操作。因此，我建议的是测试设备未连接的情况，例如，一旦设备配置或者在设备创建其数据库时，一旦设备配置，例如，就会向外部MCU发送虚拟GTL消息。在设备上也有任何外部唤醒配置，如果是，请您可以删除功能实体并检查是否创建您正在遇到的sideeffects？
谢谢mt_dialog.
在试验了你的建议之后，我们找到了一个解决方案。我们向MCU发送初始的READY消息，并接收返回的INIT消息。但是，我们在user_app_init()期间发送了READY消息，这导致了问题。如果我们根本没有发送READY消息，那么DA就会像我们预期的那样(在2秒延迟之后)直接进入睡眠状态。如果我们在user_app_on_db_init_complete()期间发送READY消息，那么睡眠仍然按照预期工作。因此，通过推迟READY消息，问题似乎就解决了。
谢谢，
保罗
嗨pvmellor，
谢谢你让我们知道，很高兴你搞清楚了。
谢谢mt_dialog.