无法使用gtl进入延长睡眠

⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
15 posts / 0 new
最后一篇
pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
无法使用gtl进入延长睡眠

我们有一个在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线以指示睡眠,但我们没有看到这样的更改。
问题的一部分是我们无法调试主循环来理解为什么它不能休眠,因为我们需要关闭调试。
如果我们让CFGŠDEVELOPMENTŠDEBUGŠ定义并调试主循环,我们*认为*我们看到它无法在rwipŠpreventŠsleepŠget()进入睡眠。
我们怀疑它是GTL的存在。这可能吗?我们如何让睡眠模式下工作?

Thanks,
保罗。

Device:
mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

Hi pvmellor,

您将不得不选择您的设备是否将使用GTL(使用外部处理器)或它将具有应用级模块(App_Task启用,独立配置)。您无法拥有两者,这就是CFG_App定义的决定。如果CFG_App定义,则如果未定义,则您将处于集成的处理器模式,然后您将处于外部模式。

谢谢mt_dialog.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
**你能优先考虑

**你能给这条线定个轻重缓急吗**
更好仍然 - 我们可以将讨论摘录作为支持机票还是呼叫/ Skype讨论?

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.

我们目前使用的架构非常类似于UM-B-017中所示的附图(jpg-in-zip),其标题为“集成处理器应用程序中的DA14580/581 GTL接口”。我们有一个集成处理器应用程序(即“任务应用程序”)和一个GTL接口,如文档所述。雷竞技安卓下载

唯一的区别是,我们使用SPI进行外部通信,而不是UART,并且我们不使用显式唤醒GPIO(为此我们使用DREADY)。

你能确认一下吗:你是说在你之前的回复中,在集成处理器应用程序中使用GTL接口是不可能的吗?不支持上述体系结构?或者我们误解了这份文件及其含义?

我们使用该文件第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处理器中运行。主机申请* /
/*是应用程序内核任务的任务*/
/* -undefined External processor mode. Host application runs on an external processor. Communicates with */
/ *通过GTL协议通过信令IFACE(UART,SPI等)* /
/ *************************************************************************************************************** /

然而,在上面提到的文件中,它说:
“如果未定义,它将启用*集成处理器应用程序*中应用程序任务的GTL/UART接口与外部处理器的通信。”

你r prompt reply would be most appreciated.
保罗。

附件:
mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

Hi pvmellor,

通常情况下,SDK如何推动Task_GTL或Task_App,我们没有任何使用的项目,SDK报告在一个应用程序任务中,我看看代码,显然它可能是合理的两者(从未在实际领域测试过,我提到的只是一个理论)。所以如果你正在做的是工作我会想你有一个定义的cfg_app,所以从堆栈到应用程序的每条消息都将结束tase_app,所以为了让一些这些消息给gtl任务我认为你正在将消息从Task_App返回到堆栈中,并将Task_GTL作为接收器,因此您在项目中正在做的是什么,因为这是我认为这将工作的唯一方法?

关于睡眠,是GTL可以影响设备的睡眠,如果设备的发射尚未结束,并且仍有需要发送的待定数据,则设备将保持醒着,直到它们。关于调试和睡眠,如果您使用的是最新的SDK,则可以执行此操作。

谢谢mt_dialog.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
谢谢你的回应。你

谢谢你的回复。关于任务应用程序和任务GTL如何为我们工作,您的假设是正确的,只是我们发送给任务GTL的消息与我们作为任务应用程序收到的消息不同:它们是我们自己定义的更高级别的特定于应用程序的消息。与UM-B-017中描述的方法类似,并使用此处规定的方法。例如:MCU初始化绑定数据库(由外部MCU存储)、启动/停止不同类型的广告、输入当前电池电压水平(MCU也会检测到这一点)、DA14580向MCU发送固件更新包以进行无线固件更新,等等。

当我们尝试睡眠时,没有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) 如果我们让CFG#DEVELOPMENT#DEBUG#定义并调试主循环,我们会认为它无法在rwipŠpreventŠsleepŠget()进入sleep。你能解释一下吗?可能与GTL有关吗?它在SDK实现中很深,我们很难调试。

4) We are using SDK 5.0.4 - is this ok for leaving development debug on?

Thanks,
保罗

mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

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.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
As per your suggestion I have

As per your suggestion I have put CFG_DEVELOPMENT_DEBUG on and debugged the sleep code/problem.

1) 为了检测睡眠,我使用了在.app\u going\u To \u sleep和.app\u resume\u from \u sleep上设置的回调来打开和关闭GPIO线以指示睡眠。仔细检查后发现,这些函数都经过了编译器的优化。在调用这些函数时,外围设备似乎已关闭,因此编译器删除了代码(令人惊讶)。我移动了代码来切换GPIO行,刚好在外设被禁用之前,这个方法用于指示睡眠。

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 -您是否能够了解这是否可以修复?见附图。我怀疑这是由于flow_on直接通过jump_表调用,然后作为gtl_exit_sleep()的一部分再次调用;但是,我无法调试回跳转表。could you explain what is happening here and who calls these jump table functions and how I can debug them?. 我也没有任何代码为gtl.c。这有空吗?

4)如果我将恢复RWIP.c放回原始状态,那么如上所述,没有睡眠。但是,在发送第一个GTL消息后,睡眠开始正常工作。所以我认为GTL必须有一个问题最初被认为是错误的状态。也许这与上面的Flow_on问题有关。你可以看看,看看这是否可以改进,或者遍布它?

Thanks,
保罗

附件:
mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

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) 关于您报告的问题,这是一个已知的问题,GTL over SPI,是的,当设备唤醒时,它会在传输时发送一个复制流,据我所知,将不会有任何操作来修复该问题(检查以确保),作为一种解决方法,您可以尝试添加一个计数器,以便在字节上发出流的次数不超过必要的次数,如下所示:

在spi\u hci\u flow\u off\u func()中应用以下内容

if(0 == flow_on_cnt)
{
返回真;
}别的
{
flow_on_cnt--;
}

在spi_hci_flow_on_func()中应用以下内容

if(flow_on_cnt > 0)
{
返回;
}别的{
flow_on_cnt ++;
}

这不是一个经过验证或测试的解决方案,但它是您可以尝试的,以避免出现两个流信号。

谢谢mt_dialog.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
谢谢你的修复

感谢您对双流动问题的修复。这已经解决了我的一个问题。
另一个问题仍然存在。让我总结一下:

我们使用GTL和集成处理器(Task_App)。Task_App通过GTL向外部处理器发送消息以执行高级应用程序特定任务。
We have extended sleep configured.
当我们启动da不睡觉时。它将正确宣传和连接和运行,但它不会睡觉。
如果我们从移动设备连接到它,并写入特征(控制点),导致DA到MCU主机发送GTL消息,那么在发送此GTL消息后立即将DA开始睡眠这应该。我们看到每个连接事件唤醒。如果我们断开我们的手机,我们会看到每个广告活动的唤醒。它适用于我们期望的,在活动之间睡觉。我们甚至可以将其放置如此睡眠,没有广告,并通过GPIO引脚上的外部唤醒活动唤醒。
所以我们认为这个问题是由于GTL消息和GTL状态。我们没有明确使用任何内核定时器。

在调试之后,我们在rwip.c中看到了两个它无法休眠的原因。

if(rwip\u prevent\u sleep\u 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,
保罗。

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
对话框 - 任何帮助

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

非常感谢,
保罗。

mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

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.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
是的 - 这就是我们的方式

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

保罗

mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

Hi pvmellor,

我的意思是,据我所知,从上面的描述,由于某种原因,我无法确定,因为我无法复制我的设置,该设备保持活跃,显然在您发送或接收GTL消息后,该设备运行正常。因此,我建议的是在设备未连接的情况下测试这种情况,例如,一旦设备得到配置,或者一旦设备创建了数据库,就向外部MCU发送一个虚拟GTL消息。另外,设备上是否有任何外部唤醒配置,如果有,请删除该功能并检查是否会产生您正在经历的副作用?

谢谢mt_dialog.

pvmellor
Offline
最后一次露面:1年6个月前
加入:2017-04-27 20:30
试验后

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

Thanks,
保罗

mt_dialog.
Offline
最后一次露面:2 months 2 weeks ago
职员
加入:2015-06-08 11:34
Hi pvmellor,

Hi pvmellor,

谢谢你让我们知道,很高兴你能弄明白。

谢谢mt_dialog.