prox_reporter rtc_interrupt_hdlr在ARCH_EXT_SLEEP_ON中触发两次

了解更多常见问题教程

8个职位/ 0个新职位
最后发表
andrewl
离线
最后看到:2天16小时前
加入:2020-11-05 02:45
prox_reporter rtc_interrupt_hdlr在ARCH_EXT_SLEEP_ON中触发两次

嗨,伙计们,

我一直在跟踪一个相当恼人的bug,最终在Dialog示例代码上复制了它。我使用CFG_EXT_SLEEP_WAKEUP_RTC设置了prox_reporter,以便通过RTC从睡眠中唤醒它。

当我使用ARCH_SLEEP_OFF运行prox_reporter时,一切都运行得很好。rtc_interrupt_hdlr每20秒触发一次(10秒的广告时间和RTC到达前10秒)。那都是鸭子。

然而,当我使用ARCH_EXT_SLEEP_ON运行prox_reporter时,在触发rtc_interrupt_hdlr之后,它会在696ms之后*再次触发。如果你想要可靠地安排一些事情,那就不好了。

这个bug似乎也影响了Timer1处理程序,因为这正是我要追踪的。我报告它在RTC上,因为它是一个*LOT*更容易和更明显的捕获这个在RTC处理程序。

这和广告间隔太接近了,不可能是巧合。BLE睡眠代码是怎么导致这种情况的?我该怎么解决这个问题?

谢谢。

设备:
PM_Dialog
离线
最后看到:11小时40分钟前
工作人员
加入:2018-02-08 11:03
嗨andrewl,

嗨andrewl,

谢谢你的问题。让我试着解释定义CFG_EXT_SLEEP_WAKEUP_RTC时prox_reporter是如何工作的。

最初,该设备将开始广告。默认的睡眠模式扩展为sleep -参见user_config.h中的app_default_sleep_mode。这意味着系统将进入延长睡眠模式之间的广告间隔,它将通过BLE定时器自动唤醒。

在一个预定义的时间(3min)后-参见user_config.h中user_default_hnd_conf结构中的.advertise_period(该值可以更改;例如12000广告12秒)-设备将停止广告,app_advertise_complete()回调将被触发,芯片将进入永久休眠模式(没有广告)。在这个回调中,RTC被配置为从扩展的sleep触发唤醒中断-参见configure_rtc_wakeup()。

如果您进入configure_rtc_wake(),在rtc_time_t时间内,您可以找到RTC配置:11h, 55min, 30秒)。因此,rtc_interrupt_hdlr()将在广告停止后,在11h 55min 30秒后触发,然后芯片将被唤醒。

我建议您做一个快速测试,并使用SmartSnippets工具箱功率分析器进行验证。

将广告周期更改为12秒:.advertise_period = MS_TO_TIMERUNITS(12000),

配置RTC在15秒后唤醒DA14531:

Rtc_time_t time ={。小时模式= RTC_HOUR_MODE_24H, .pm_flag = 0, .hour = 00, .minute = 00, .sec = 5, .hsec = 00};

谢谢,PM_Dialog

andrewl
离线
最后看到:2天16小时前
加入:2020-11-05 02:45

嗨,PM_Dialog,

>在预定义的时间(3min)后-参见user_config.h中user_default_hnd_conf结构中的.advertise_period(该值可以更改;例如12000个广告12秒)

是的,默认值是3分钟,我把这个值调低了,这样我可以更快地复制bug。

>如果你进入configure_rtc_wakeup(),在rtc_time_t时间,你可以找到RTC配置:11h, 55min, 30秒)。因此,rtc_interrupt_hdlr()将在广告停止后,在11h 55min 30秒后触发,然后芯片将被唤醒。

不,那是这是如何工作的。configure_rtc_wakeup()将每次传递的时间重置为11:55:30,这样它就可以始终将闹钟设置在相对于该时间的10秒以后。因此,每当configure_rtc_wake()在app_advertise_complete()的末尾触发时,RTC时间将被重置,并在未来10秒内设置闹钟。

然后rtc_interrupt_hdlr()在未来10秒触发(sleep+10s)。这很好。如果设置了ARCH_EXT_SLEEP_ON,问题是它*也*在696ms后再次触发(sleep+10+.696s)。那不是很好。

我为一个bug提供了一个可靠的解释。我已经在安捷伦示波器和吉思利源计上验证过了。我一直在寻找它,我提出了一种在Dialog代码中复制它的方法。除非响应返回时讨论中断屏蔽和可能的优先级反转,否则它可能不是一个答案。

>我建议您做一个快速测试,并使用SmartSnippets工具箱电源分析器验证它。

我建议你把这张票交给带示波器的人。我该如何将其升级?

谢谢。

PM_Dialog
离线
最后看到:11小时40分钟前
工作人员
加入:2018-02-08 11:03
嗨andrewl,

嗨andrewl,

谢谢你的评论。我会内部调查此事,然后再联系你。

谢谢,PM_Dialog

andrewl
离线
最后看到:2天16小时前
加入:2020-11-05 02:45
感谢。谢谢你

感谢。谢谢你这么做。

PM_Dialog
离线
最后看到:11小时40分钟前
工作人员
加入:2018-02-08 11:03
嗨andrewl,

嗨andrewl,

请检查configure_rtc_wakeup()。当通告停止时触发此功能,以便将RTC配置为唤醒源。

根据configure_rtc_wakeup(),告警中断被显式设置为10秒- alarm_time。秒+ = 10;

rtc_set_alarm(),以alarm_time和RTC_ALARM_EN_SEC作为输入参数(使能在Time alarm Register中达到sec时触发告警)

因此,当告警事件发生时(每10秒一次),rtc_interrupt_hdlr将产生一个中断。

如果修改了alarm_time。SEC + = 2,您将看到rtc_interrupt_hdlr每4秒启动一次。

谢谢,PM_Dialog

andrewl
离线
最后看到:2天16小时前
加入:2020-11-05 02:45
>因此,rtc_interrupt_hdlr

>因此,rtc_interrupt_hdlr将在告警事件发生时产生一个中断(每10秒一次)。

是的,这是真的。但是当它进入睡眠状态时,它也会在696毫秒后产生另一个中断。为什么?

当我建议你们找一个带示波器的人的时候,我是有点生气;但是,如果不这样做,您将无法调试它。

如果您有一些依赖于正确触发的处理程序,则此bug会导致打嗝。

谢谢。

PM_Dialog
离线
最后看到:11小时40分钟前
工作人员
加入:2018-02-08 11:03
嗨andrewl,

嗨andrewl,

我正在查,一会再联系你。

谢谢,PM_Dialog