Cannot enter extended sleep with GTL

**COULD YOU PLEASE PRIORITISE 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

/ *************************************************************************************************************** /
/* Integrated or external processor configuration */
/ * - 定义集成处理器模式。主机应用程序在DA14580处理器中运行。主机申请* /
/* is the TASK_APP kernel task. */
/* -undefined External processor mode. Host application runs on an external processor. Communicates with */
/* BLE application through GTL protocol over a signalling iface (UART, SPi etc) */
/ *************************************************************************************************************** /

Yet in the document mentioned above it says:
"If undefined, it will enable the communication over GTL/UART interface of application task in *integrated processor application* with an external processor."

Your prompt reply would be most appreciated.
Paul.

Thanks for the response. You 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.

There are no GTL messages pending or in transmission when we attempt to sleep. GTL messages are not sent particularly often - generally just at start up time and when there is a connection in progress and the end use is doing a data sync or firmware update.

大部分时间设备都不处于连接状态，也不是广告。它将简单地睡着了等待来自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) Since there is no GTL activity in place or pending, could you help us to understand what could be preventing the device from sleeping? This is the most important question for us to answer right now. What do we need to test? What can we do?

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,
Paul

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) If I put the restore rwip.c back to its original state, then as stated above there is no sleep. However, after the first GTL message is sent, then sleep start working normally. So I think there must be an issue with the GTL being considered to be in the wrong state initially. Perhaps this is related to the flow_on issue above.你可以看看，看看这是否可以改进，或者遍布它？

Thanks,
Paul

Thanks for the fix for the dual flow-on problem. This has solved one of my problems.
其他问题仍然存在。让我总结：

We use GTL and an integrated processor (TASK_APP). TASK_APP sends messages to the external processor via GTL to perform high-level application specific tasks.
We have extended sleep configured.
When we start up the DA does not sleep. It will advertise and connect and function properly, but it does not sleep.
If we connect to it from a mobile device, and write to a characteristic (control point) that results in a GTL message being sent by the DA to the MCU host, then immediately after this GTL message has been sent the DA starts to sleep as it should. We see it wake for each connection event. If we disconnect our mobile we see it wake for each advertise event. It works as we would expect, sleeping in between events. We can even put it so sleep with no advertising and wake it via an external wakeup event on a GPIO pin.
所以我们认为这个问题是由于GTL消息和GTL状态。我们没有明确使用任何内核定时器。

After debugging we see two reasons it will not sleep, in rwip.c.

if (rwip_prevent_sleep_get() != 0)
break;

This line prevents it getting further (i.e. the break is executed). This is because rwip_prevent_sleep_get() is returning RW_GTL_TIMEOUT. So we use

rwip_prevent_sleep_clear(RW_GTL_TIMEOUT);

在我们的初始代码中，这条线路不再阻止我们睡觉。

The second problem is with

if (ble_intrawstat_get() & BLE_GROSSTGTIMINTRAWSTAT_BIT)
break;

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);

在我们的初始化代码中，但这并没有帮助 - 它正在其他地方设置。

Could you help with more information about this bit and what it is doing and how it is set and how it may be related to the GTL interface. Or - better still - can you suggest a fix as you did for the previous problem?

Thanks,
Paul.

对话框 - 任何帮助on the above issue?
它正在举起我们的发展，我们没有很多时间剩下！

Many thanks,
Paul.

是的,这就是我们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.

Paul

在尝试完成您的建议之后，我们发现了一个解决方案。我们正在向MCU发送初始准备消息，并接收init消息。但是，我们在user_app_init（）期间发送了就绪消息，这导致了问题。如果我们根本没有发送就绪消息，那么DA直接睡觉（在我们预期的2秒延迟之后）。如果我们在user_app_on_db_init_complete（）期间发送就绪消息，那么睡眠仍然按预期工作。因此，通过延迟就绪的消息，问题似乎已经解决。

Thanks,
Paul