嗨伙计，
我一直在跟踪一个相当刺激的错误，我终于设法在对话框示例代码上重现它。我使用CFG_EXT_SLEEP_WAKEUP_RTC设置PROX_REPORTER，以便通过RTC从睡眠中唤醒。
当我用arch_sleep_off运行prox_reporter时，一切都很好。RTC_INTRUPT_HDLR每20秒开始一次（10秒的广告和rTC命中前10秒）。这只是鸭子。
However, when I run the prox_reporter with ARCH_EXT_SLEEP_ON, after rtc_interrupt_hdlr fires, it then fires *again* 696ms later. That's not good if you're trying to schedule something reliably.
此错误似乎也影响Timer1处理程序，因为这就是我正在跟踪的。我在RTC上报告它，因为它是一个*很多*在RTC处理程序上捕获这一点更容易且更明显。
这太接近了广告间隔是巧合的。什么是ble睡觉代码来引起这个？我如何解决这个问题？
Thanks.
Device:
Hi andrewl,
谢谢你的问题。让我试着解释Prox_reporter如何在定义CFG_EXT_SLEEP_WAKEUP_RTC时如何运行。
最初，设备将开始向上。默认睡眠模式延长睡眠 - 请参阅user_config.h中的app_default_sleep_mode。这意味着系统将在广告间隔之间进入扩展的睡眠模式，并且它将通过BLE定时器自动唤醒。
在预定义的时间（3min）之后 - 请参阅user_default_hnd_ponf结构中的，在user_config.h中查看（此值可以更改;例如，12000为12sec的广告） - 设备将停止副词，并且将触发app_advertise_complete（）回调芯片将进入永久睡眠模式（无广告）。在此回调中，RTC配置为触发延长睡眠中的唤醒中断 - 请参阅configure_rtc_wakeup（）。
如果在CONFIGURE_RTC_WAKEUP（）中，请在RTC_TIME_T中找到RTC配置：11h，55min，30秒）。因此，将在广告已停止时触发RTC_Interrupt_hdlr（），在11h，55min，30秒之后，芯片将唤醒。
我建议您使用SmartSnippets Toolbox Power Profiler进行快速测试并验证它。
将广告期更改为12秒：.advertise_period = MS_TO_TIMERUNITS（12000），
在15秒后，配置RTC唤醒DA14531：
谢谢，PM_DIALOG.
嗨，pm_dialog，
>在预定义的时间（3min）之后 - 请参阅user_default_hnd_conf结构中的，请参阅user_config.h中的Advertise_Period（此值可以更改;例如12SEC的12000广告）
Yes, the default is 3 min, I changed this down so that I could replicate the bug more quickly.
> If you go inside the configure_rtc_wakeup(), in the rtc_time_t time you can find the RTC configuration: 11h , 55min, 30 sec ) . So, the rtc_interrupt_hdlr() will be triggered when the advertisement has been stopped and after 11h , 55min, 30 sec and then chip will wake up.
不，那是NOThow this works. The configure_rtc_wakeup() resets the time to 11:55:30 every pass through so that it can always set the alarm 10 seconds in the future relative to that. So, whenever configure_rtc_wakeup() fires at the end of app_advertise_complete(), the RTC time gets reset and the alarm gets set for 10 seconds in the future.
RTC_INTRUPT_HDLR（）将来（睡眠+ 10s）触发10秒。没关系。如果设置了ARCH_EXT_SLEEP_ON，则问题是它*也*再次触发696ms（睡眠+ 10 + .696s）。那不好。
I provided a solid explanation of a bug. I have verified it both on my Agilent Oscilloscope and my Keithley Sourcemeter. I've been down the rabbit hole hunting it, and I presented a way to replicate it in Dialog code. Unless the response comes back talking about interrupt masking and possibly priority inversion, it's probably not an answer.
>我建议您使用SmartSnippets Toolbox Power Profiler进行快速测试并验证它。
I would recommend you hand this ticket off to someone with an oscilloscope. How do I escalate this?
Thanks.
Hi andrewl,
感谢您的意见。我将在内部升级这个，开始调查这个，我会回复你。
谢谢，PM_DIALOG.
非常感激。谢谢你这样做。
Hi andrewl,
请检查configure_rtc_wakeup（）。当广告已停止时触发此功能以便将RTC作为唤醒源配置RTC。
根据configure_rtc_wakeup（），警报中断明确设置为10秒 - Alarm_time.sec + = 10;
The rtc_set_alarm(), takes as an input parameter the alarm_time and the RTC_ALARM_EN_SEC (Enable to trigger alarm when the sec in Time Alarm Register has been reached)
So, the rtc_interrupt_hdlr will generate an interrupt when alarm event occurs (every 10 seconds.)
If you change the alarm_time.sec + = 2 , you will see that the rtc_interrupt_hdlr fires up every 4 seconds.
谢谢，PM_DIALOG.
>因此，RTC_INTRUPT_HDLR将在发生警报事件时生成中断（每10秒钟。）
是的，这是真的。但它*也*在睡觉时稍后在稍后产生另一个中断。为什么？
I was emitting more than a little pique when I suggested that you find someone with an oscilloscope; however, you're not going to be able to debug this without doing that.
如果您有依赖于处理程序触发的内容，则此错误会导致打嗝。
Thanks.
Hi andrewl,
I am working on this, so I'll get back to you.
谢谢，PM_DIALOG.
Hi andrewl,
抱歉为延迟。不幸的是,我不能to replicate this. I am toggling the P08 when the configure_rtc_wakeup() is triggered and the P09 when the rtc_interrupt_hdlr() is triggered. Please see the attached screenshot. I probe the P08 and P09 with a logic analyzer. The rtc_interrupt_hdlr() does not fire again 696ms later.
该设备是使用5秒钟的，并且CONFIGURE_RTC_WAKEUP（）在4秒后执行。
请您可以分享示波器的屏幕截图，以便我能够更好地理解它？
谢谢，PM_DIALOG.
当然。给我几天。I'm in the process of moving this over to the "simple beacon" codebase which invokes quite a lot less machinery. This should make it much easier to track down.