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?

我们已完成硬件设计和构建，并非常接近完成我们的固件开发。您的回复似乎表明我们有一个阻塞问题，这可能需要我们交换给不同的BLE提供商/解决方案。因此，我们需要尽快解决这个问题。

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.

The only differences are that we use SPI for external communications, not UART, and we do not use the explicit Wakeup GPIO (we use DREADY for this purpose).

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?

We use the transport format as described in that document section 5, we define our own set of application level messages and handlers in app.h as defined in section 6. Section 7 discusses the max sleep period while GTL is in use, but we have not yet got to this point. Our code is stable and has been running well for some time passing GTL messages to our external MCU. However, our application will not go into (extended) sleep.

如果支持附加图中的架构，请您可以帮助我们了解我们所需要的更改需要更改以进行更改吗？我们需要一个task_app（如图所示）来处理配置文件相关的消息交换（Create_DB，启用/禁用，写入指示等），以及GTL接口，以在较少频繁的基础上使用外部处理器交换高级消息发生特定的应用程序级事件。我们还支持播放和低音配置文件（并且可以在未来添加其他人）。

我们发现CFG_APP围绕混淆的文档。config_basic.h文件中的注释说

/***************************************************************************************************************/
/* Integrated or external processor configuration */
/* -defined Integrated processor mode. Host application runs in DA14580 processor. Host application */
/* is the TASK_APP kernel task. */
/ * - 义外部处理器模式。主机应用程序在外部处理器上运行。与* /沟通沟通
/* 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."

您的迅速答复将最受欢迎。
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.

Most of the time the device is not in a connected state, and is not advertising either. It will simply be asleep waiting for a wake up signal from the MCU (the device is motion sensitive and wakes on motion). At other times it is advertising and sleep is again required to conserve power.

Note we are working on the PAN1740ETU evaluation module with Segger J-Link debugger for testing, and on our own boards.

我们在广告时每376毫秒查看App_on_ble_powered（）和app_on_system_powered（）调用的调用，每376ms连接。

Some specific questions then:

1) If our scenario/architecture is rare and untested, how come there is a document UM-B-017, which is entitled "DA14580/581 GTL interface in integrated processor applications" that specifically describes it? Have we misunderstood this document? It seems to represent exactly this architecture and describes how to use it.

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）我们使用的是SDK 5.0.4 - 这是可以留下开发调试的吗？

谢谢，
Paul

根据您的建议，我已经将CFG_Development_debug放在上面并调试睡眠代码/问题。

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) There are three places in rwip_sleep() that were preventing it from sleeping.
rwip_prevent_sleep_get)测试()
b）通过（ble_intrawstat_get（）和ble_grosstgtimintrawstat_bit的内核定时器测试
c) Same as above - but a second test of the kernel timers.
With these three tests commented out, the device DID go into extended sleep. I have nice traces of it sleeping and waking for advertising at 376ms, and when I connect I see it sleeping and waking at 48ms for connection events. If I turn advertising off, then it will sleep and wake as per the CFG_MAX_SLEEP_DURATION_PERIODIC_WAKEUP_MS timer. I currently have this set up to 600,000 (ten minutes) and working fine (original value was 500 for 0.5 seconds).

3）在每个唤醒/睡眠期间，再次启用GTL接口。但有一个问题。每次发送两个流字节，然后在设备再次休眠时，然后流关闭。这会导致MCU上的GTL协议代码出现问题 -您是否能够了解这是否可以修复？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.你能解释这里正在发生的事情，谁叫这些跳跃表函数以及如何调试它们？. 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.could you have a look and see if this could be improved, or worked around?

谢谢，
Paul

Thanks for the fix for the dual flow-on problem. This has solved one of my problems.
The other problem remains. Let me summarise:

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.
我们已扩展睡眠配置。
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.
So we believe this problem is due to the GTL message and the GTL state. We do not explicitly use any kernel timers.

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

in our initialisation code and this line no longer prevents us sleeping.

The second problem is with

if (ble_intrawstat_get() & BLE_GROSSTGTIMINTRAWSTAT_BIT)
break;

BLE_GROSSTGTIMINTRAWSTAT_BIT位设置并防止睡眠。我们没有多少数据关于该位，并且在代码中没有明确设置任何地方。我们尝试过

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?

谢谢，
Paul.

对话框 - 上述问题的任何帮助？
It is holding up our development and we do not have a lot of time left!

Many thanks,
Paul.

是的 - 这就是我们现在的工作方式。我们通过移动设备连接到设备，然后手动导致要发送的虚拟消息。然后，这将开始睡觉的设备。

Paul

After experimenting with your suggestions we found a solution. We were sending an initial READY message to the MCU, and receiving back an INIT message. However, we sent the READY message during user_app_init() and this caused the problem. If we did not send the READY message at all then the DA went into sleep straight away (after the 2 sec delay) as we expected. If we send the READY message during user_app_on_db_init_complete() then sleep still worked as expected. So by delaying the READY message the problem seems to be solved.

谢谢，
Paul