我有一个连接到我用来触发若干行为的按钮的中断。
我发现在OTP之后，其中一些行为不正常，我将其归因于睡眠模式，导致我在某处丢失数据或中断DMA等操作。
我正在试验另一种架构，其中中断设置一个标志，导致这些行为在主循环中执行，所以我可以更好地控制事件的时间和顺序，但我有一个漏洞，我正在努力关闭。
如果我的中断在我的app_on_system_powered函数返回GOTO_SLEEP和中断被禁用为睡眠模式之间被触发，那么我不能依赖标志被快速拾取。
有没有办法让我中止睡眠模式，或者立即退出它，如果在该机会的窗口中发生了什么？我已经注意到了App_Goop_To_sleep作为检查此条件的机会，因为中断已经被该点禁用，但我看不到任何明显的事情要做。
设备:
嗨,埃里克Scammell
请检查SDK6.0.4的ble示例中的睡眠模式示例。如果你不调用中断，设备将再次唤醒，当你按下按钮时，一个中断被调用(不是唤醒中断)，这会导致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时，这些错误就会出现，此时它们就变得非常难以诊断。我怀疑在OTP之前和之后唯一会给我的程序带来问题的行为变化是睡眠模式，所以我试图非常小心地安排我的操作，以便它们不会被睡眠打断。
你好再次,
在唤醒中断的情况下，BLE程序将再次启动(从头开始)有一个延迟。在我之前提到的其他情况下，当所有的中断被禁用，设备将进入睡眠状态，如果从按钮调用一个中断(它将挂起)，WFI(将等待中断)，并将从开始启动过程。请检查您是否已将缓冲区的数据放入保留存储器，否则在休眠模式下数据将会丢失。
谢谢,
STS_Dialog。
你好,
我对代码的解释是，如果中断在错误的时间被触发，有可能发生以下事件:
1)决定在app_on_system_powered中返回GOTO_SLEEP
2)中断被触发，并成为挂起
3)中断服务
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。