我有一个中断连接到一个按钮，我用它来触发几个行为。
我发现有些行为在OTP后不正常，我将其归因于睡眠模式，导致我在某处丢失数据或中断DMA等操作。
我正在试验一种替代架构，其中中断设置一个标志，导致这些行为在主循环中执行，这样我就可以更好地控制事件的时间和顺序，但我有一个漏洞，我正在努力关闭。
如果我的中断触发我的app_on_system_powered函数返回GOTO_SLEEP和中断被禁用为睡眠模式，那么我不能依赖于标记被快速拾取。
有没有办法让我中止睡眠模式，或者立即退出，如果机会之窗发生了什么事?我将app_going_to_sleep作为检查这种情况的机会，因为到那时中断已经被禁用了，但是我看不到任何明显的可以做的事情。
设备:
嗨,埃里克Scammell
请查看SDK6.0.4的ble examples中的睡眠模式示例。如果你不调用中断，设备将再次唤醒，当你按下按钮一个中断被调用(不是唤醒中断)，这导致WFI，所以设备在这种情况下不休眠。请给我更多关于“after OTP”使用的信息，你的目的到底是什么?
谢谢,
STS_Dialog。
嗨STS,
当我按下按钮时，我并不担心芯片已经休眠或将要休眠的情况。我用的是wkupct定时器，所以芯片会有良好的响应。
问题是在我的app_on_system_powered实现的末端和准备休眠的芯片之间有一个非常小的窗口(在arch_main.c的第162-168行期间)。在该窗口期间，如果我的中断被调用，它将设置标志，然后芯片将休眠。在这种情况下，直到芯片下一次醒来(可能是几秒钟)，旗子才会起作用。我不能指望开关中断结束睡眠状态，因为它将在WFI上芯片停止之前被清除。
我认为最简单的解决方案是，如果我看到我的标志被设置，以便WFI立即返回，那么从app_going_to_sleep引发一个中断，但我看不到从软件做到这一点的简单方法。
关于OTP，我看到了许多在我的调试环境中没有出现的bug。当我将程序提交给OTP时，这些bug就会出现，这时它们就很难诊断了。在OTP之前和之后的行为的唯一变化，我怀疑会给我的程序问题是睡眠模式，所以我试图非常小心地命令我的操作，使他们不被睡眠打断。
你好再次,
在唤醒中断的情况下，BLE过程将有一个重新开始(从头开始)的延迟。在其他情况下，如我前面提到的，当所有中断都被禁用，设备将进入睡眠状态，例如，如果一个来自按钮的中断被调用(它将挂起)，WFI(将等待中断)将从开始开始这个过程。请检查您是否已经将您的缓冲区的数据在保留记忆，否则在睡眠模式下的数据将丢失。
谢谢,
STS_Dialog。
你好,
我对代码的解释允许一种可能性，如果中断在完全错误的时间触发，以下事件序列:
1)在app_on_system_powered中决定返回GOTO_SLEEP
2)中断被触发，并变成待定
中断服务
4)在准备睡眠模式时，中断被禁用
5)注射
如果发生这种情况，那么在WFI中就不再有一个挂起的中断。
这对我来说是个问题，因为我首选的中断实现要求在中断服务之后很快调用app_on_system_powered。
我不担心需要在app_on_system_powered中执行的操作不会发生，因为我的标志在保留内存中，但它需要在几十或几百毫秒内发生。如果我不能指望在这种情况下摆脱睡眠模式，延迟可能会更久。
我是否误解了这种可能性，或者我没有清楚地传达我所需要的?
你好,
在ISR中将调用arch_force_active_mode()函数来停止睡眠模式。此事件设置sleep_mode=mode_active。在使用该标志的地方，将使用arch_restore_sleep_mode()函数。
谢谢,
STS_Dialog。