我们有一个在Pan1740模块上运行的应用程序。我们在DA14580上处理大多数邮件，但我们确实在SPI上有一个外部接口到MCU。通信使用GTL（即GTL接口与集成处理器应用程序“）。
我们现在正在尝试使我们的工作应用程序运行，并启用扩展休眠状态。我们有正确的东西定义我相信......
#define cfg_gtl_spi.
#define 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线以指示睡眠，但我们没有看到这样的更改。
Part of the problem is that we cannot debug the main loop to understand why it does not sleep as we need to turn debugging off.
If we leave CFG_DEVELOPMENT_DEBUG #defined and debug the main loop we *think* we see it failing to enter sleep at rwip_prevent_sleep_get().
我们怀疑它是GTL的存在。这可能吗？我们如何让睡眠模式下工作？
Thanks,
保罗。
Device:
Hi pvmellor,
您将不得不选择您的设备是否将使用GTL（使用外部处理器）或它将具有应用级模块（App_Task启用，独立配置）。您无法拥有两者，这就是CFG_App定义的决定。如果CFG_App定义，则如果未定义，则您将处于集成的处理器模式，然后您将处于外部模式。
谢谢mt_dialog.
**你能优先考虑THIS THREAD**
Better still - could we take the discussion off line as a support ticket or and have a call/skype to discuss?
We have completed our hardware design and build and are very close to completing our firmware development. Your response would seem to indicate we have a blocking problem that may necessitate us swapping to a different BLE provider/solution. Hence we need to resolve this issue ASAP.
We are currently using an architecture very similar to the diagram attached (jpg in zip) as shown in UM-B-017, which is entitled "DA14580/581 GTL interface in integrated processor applications". We have an integrated processor application (i.e. a "task app") and also a GTL interface, as the document describes.
唯一的差异是我们使用SPI进行外部通信，而不是UART，我们不使用显式唤醒GPIO（我们为此目的使用Dreadey）。
Could you confirm: are you saying as in your previous reply that is it not possible to use the GTL interface in an integrated processor application? That the architecture above is not supported? Or perhaps we have misunderstood this document and its meaning?
我们使用该文件第5节中所述的传输格式，我们在App.h中定义了我们自己的一组应用程序级别消息和处理程序，如第6节所定义。第7节讨论了GTL在使用中的最大睡眠期间，但我们有尚未达到这一点。我们的代码稳定，一直运行良好，一段时间通过GTL消息传递给我们的外部MCU。但是，我们的申请不会进入（延长）睡眠。
If the architecture in the diagram attached is supported, could you please help us understand what we would need to change to implement it as described? We require a TASK_APP (as shown in the diagram) to handle the profile related message exchanges (create_db, enable/disable, write indications etc), plus a GTL interface to exchange high level messages with an external processor on a less frequent basis when a specific application level event occurs. We also support the DISS and BASS profiles (and may add additional ones in the future).
We find the documentation around CFG_APP confusing. The comment in the config_basic.h file says
/ *************************************************************************************************************** /
/ *集成或外部处理器配置* /
/ * - 定义集成处理器模式。主机应用程序在DA14580处理器中运行。主机申请* /
/* is the TASK_APP kernel task. */
/* -undefined External processor mode. Host application runs on an external processor. Communicates with */
/ *通过GTL协议通过信令IFACE（UART，SPI等）* /
/ *************************************************************************************************************** /
然而，在上面提到的文件中，它说：
"If undefined, it will enable the communication over GTL/UART interface of application task in *integrated processor application* with an external processor."
你r prompt reply would be most appreciated.
保罗。
Hi pvmellor,
通常情况下，SDK如何推动Task_GTL或Task_App，我们没有任何使用的项目，SDK报告在一个应用程序任务中，我看看代码，显然它可能是合理的两者（从未在实际领域测试过，我提到的只是一个理论）。所以如果你正在做的是工作我会想你有一个定义的cfg_app，所以从堆栈到应用程序的每条消息都将结束tase_app，所以为了让一些这些消息给gtl任务我认为你正在将消息从Task_App返回到堆栈中，并将Task_GTL作为接收器，因此您在项目中正在做的是什么，因为这是我认为这将工作的唯一方法？
关于睡眠，是GTL可以影响设备的睡眠，如果设备的发射尚未结束，并且仍有需要发送的待定数据，则设备将保持醒着，直到它们。关于调试和睡眠，如果您使用的是最新的SDK，则可以执行此操作。
谢谢mt_dialog.
谢谢你的回应。你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评估模块进行测试，并在我们自己的电路板上。
We do see calls to app_on_ble_powered() and app_on_system_powered() calls every 376ms when advertising and every 48.75ms when connected.
然后是一些具体问题：
1）如果我们的方案/架构是罕见和未经测试的，那么如何出现文件UM-B-017，其题为“集成处理器应用程序中的DA14580 / 581 GTL接口”，具体描述它？雷竞技安卓下载我们误解了这份文件吗？它似乎代表了这种架构，并描述了如何使用它。
2）由于没有地理位置或待处理的GTL活动，因为您可以帮助我们理解可能阻止设备睡觉的内容吗？这是我们现在回答最重要的问题。我们需要测试什么？我们可以做什么？
3) If we leave CFG_DEVELOPMENT_DEBUG #defined and debug the main loop we think we see it failing to enter sleep at rwip_prevent_sleep_get(). Could you explain this? Could it be related to the GTL? It is deep in the SDK implementation and difficult for us to debug.
4) We are using SDK 5.0.4 - is this ok for leaving development debug on?
Thanks,
保罗
Hi pvmellor,
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.
As per your suggestion I have put CFG_DEVELOPMENT_DEBUG on and debugged the sleep code/problem.
1) To detect sleep I was using the callbacks set up on .app_going_to_sleep and .app_resume_from_sleep to toggle a GPIO line on and off to indicate sleep. Closer inspection showed that these functions where optimised out by the compiler. It seems that the peripherals are switched off by the time these functions are called, so the code was removed by the compiler (surprising). I moved the code to toggle the GPIO lines to just before the peripherals are disabled and this method worked to indicate sleep.
2）Rwip_sleep（）中有三个地方，防止它睡觉。
a）RWIP_PREVENT_SLEEP_GET的测试（）
b) A test of the kernel timers via (ble_intrawstat_get() & BLE_GROSSTGTIMINTRAWSTAT_BIT)
c）与上述相同 - 但是内核定时器的第二次测试。
使用这三个测试注释出来，设备确实进入了睡眠状态。我有漂亮的痕迹，睡觉和醒来，为376毫秒广告，当我连接时，我看到它睡觉并在48ms中醒来以进行连接事件。如果我转过来，那么它将根据CFG_MAX_SLEEP_DOURATION_PERIODIC_WAKEUP_MS计时器睡眠和唤醒。我目前拥有高达600,000（十分钟），工作正常（原始值为500秒，0.5秒）。
3) During each wake/sleep period the GTL interface is enabled again. But there is a problem. TWO flow-on bytes are sent each time, followed by a flow-off when the device sleeps again. This causes problems with my GTL protocol code on the MCU -您是否能够了解这是否可以修复？See attached diagram. I suspect it is due to flow_on being called directly via the jump_table, and then perhaps being called again as part of gtl_exit_sleep(); However, I cannot debug back past the jump table.could you explain what is happening here and who calls these jump table functions and how I can debug them?。Also I do not have any code for gtl.c. Is this available?
4）如果我将恢复RWIP.c放回原始状态，那么如上所述，没有睡眠。但是，在发送第一个GTL消息后，睡眠开始正常工作。所以我认为GTL必须有一个问题最初被认为是错误的状态。也许这与上面的Flow_on问题有关。你可以看看，看看这是否可以改进，或者遍布它？
Thanks,
保罗
Hi pvmellor,
2 - 3) rwip_sleep()在上述检查order to see if anything of the above has a pending procedure and if it has it wont go to sleep, commenting out those conditions would not be wise or recommended since the device will go to sleep regardless if there is something to do or not. In order for the device to go sleep it pass through those checks and decides. Do you see that the device always breaks and never reaches the PROGRAM CORE DEEP SLEEP that will signal the beggining of the sleep period ? If you mention that the device is cancelling sleep due to the in the kernel timers can you please check what will happen if you remove the timers (if you are using any) from the project (just for a test) ? Also can you please remove the GTL and check if the device has still the same behaviour ? Just try to use your application as a standalone device and verify that the device goes into sleep mode. Then you can re-apply the GTL configurations and check if the GTL cause the issue of the sleep. Try to see if there is any pending command from the external host or a signal in the interface that keeps the device awaken.
I was able to use the ble_app_peripheral example and apply the SPI GTL configuration on that project, then i ve used the proximity reporter host project (host_proxr project on another 580) to act as a host on the fully embedded / GTL modified project, i couldn't find any issues in sleeping when the application from the external host (send GTL messages from the TASK_APP from the fully hosted project to the host when writing a custom characteristic).
4) Regarding the problem that you are reporting, this is a known issue with the GTL over SPI and yes it sends a duplicate flow on transmit when the device is waking up, and as far as i am aware there is going to be no action to fix the issue (checking on that to be sure), what you can try as a work around would be to add a counter in order not issue a flow on byte more times than they are neccessary, like below:
spi_hci_flow_off_func应用下列()
if（0 == flow_on_cnt）
{
返回真;
}别的
{
flow_on_cnt--;
}
在spi_hci_flow_on_func（）中应用以下内容
if(flow_on_cnt > 0)
{
返回;
}别的{
flow_on_cnt++;
}
This is not a verified or tested solution, but its something you can try in order not have two flow on signals.
谢谢mt_dialog.
感谢您对双流动问题的修复。这已经解决了我的一个问题。
其他问题仍然存在。让我总结：
我们使用GTL和集成处理器（Task_App）。Task_App通过GTL向外部处理器发送消息以执行高级应用程序特定任务。
We have extended sleep configured.
当我们启动da不睡觉时。它将正确宣传和连接和运行，但它不会睡觉。
如果我们从移动设备连接到它，并写入特征（控制点），导致DA到MCU主机发送GTL消息，那么在发送此GTL消息后立即将DA开始睡眠这应该。我们看到每个连接事件唤醒。如果我们断开我们的手机，我们会看到每个广告活动的唤醒。它适用于我们期望的，在活动之间睡觉。我们甚至可以将其放置如此睡眠，没有广告，并通过GPIO引脚上的外部唤醒活动唤醒。
所以我们认为这个问题是由于GTL消息和GTL状态。我们没有明确使用任何内核定时器。
After debugging we see two reasons it will not sleep, in 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）
休息;
The BLE_GROSSTGTIMINTRAWSTAT_BIT bit is set and prevents sleep. We don't have much data about this bit and it is no explicitly set anywhere in the code. We have tried using
REG_BLE_WR（BLE_INTRAWSTAT_ADDR，BLE_INTRAWSTAT_RESET）;
在我们的初始化代码中，但这并没有帮助 - 它正在其他地方设置。
您是否可以帮助更多有关此位的信息以及它在做什么以及它是如何设置的以及它如何与GTL接口相关。或者 - 更好的 - 你可以建议你对之前的问题做的修复吗？
Thanks,
保罗。
对话框 - 任何帮助on the above issue?
它正在举起我们的发展，我们没有很多时间剩下！
Many thanks,
保罗。
Hi pvmellor,
The part that you mention that the device stops is for checking the timers that are set, and if there is a timer about to expire then the device will cancel the sleeping procedure. Since the device goes to sleep when there is a message exchange over the GTL layer, have you tried to exchange a dummy message between the device and host and check if that will force the device to go to sleep ?
谢谢mt_dialog.
是的 - 这就是我们的方式working now. We connect to the device via mobile and then manually cause a dummy message to be sent. This then starts the device sleeping as it should.
保罗
Hi pvmellor,
What i mean is that as far as i can understand from the description above, for some reason that i am not able to determine since i am not able to replicate on my setup, the device stays active and apparently after you send or receive a GTL message the device operates as it should. So what i am suggesting is to test that case when the device is not connected, for example send a dummy GTL message to the external MCU as soon as the device gets configured or as soon as the device creates its database. Also is there any external wake up configuration on the device, if yes, can you please remove the functionallity and check if that creates the sideeffects that you are experiencing ?
谢谢mt_dialog.
在尝试完成您的建议之后，我们发现了一个解决方案。我们正在向MCU发送初始准备消息，并接收init消息。但是，我们在user_app_init（）期间发送了就绪消息，这导致了问题。如果我们根本没有发送就绪消息，那么DA直接睡觉（在我们预期的2秒延迟之后）。如果我们在user_app_on_db_init_complete（）期间发送就绪消息，那么睡眠仍然按预期工作。因此，通过延迟就绪的消息，问题似乎已经解决。
Thanks,
保罗
Hi pvmellor,
Thanks for letting us know, glad you figure this out.
谢谢mt_dialog.