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.

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.

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 */
/* -defined Integrated processor mode. Host application runs in DA14580 processor. Host application */
/* 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.

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.

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.

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) 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) There are three places in rwip_sleep() that were preventing it from sleeping.
一个) A test of rwip_prevent_sleep_get()
b) A test of the kernel timers via (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) 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.could you have a look and see if this could be improved, or worked around?

Thanks,
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.
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.
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;

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.

Dialog - any chance of help on the above issue?
It is holding up our development and we do not have a lot of time left!

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

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.

Thanks,
Paul