我有一个连接到我用来触发若干行为的按钮的中断。
我发现在OTP之后的一些行为行为不端行为，我归因于睡眠模式，导致我丢失某处或中断操作，如DMA。
我正在尝试使用中断设置一个标志，以使这些行为在主循环中执行，因此我可以更好地控制事件的时序和顺序，但我有一个漏洞我正在努力关。
如果我的app_on_system_powered函数之间的中断触发返回goto_sleep并且禁用睡眠模式的中断然后我不能依赖于快速拾取的标志。
有没有办法让我中止睡眠模式，或者立即退出它，如果在该机会的窗口中发生了什么？我已经注意到了App_Goop_To_sleep作为检查此条件的机会，因为中断已经被该点禁用，但我看不到任何明显的事情要做。
设备：
嗨Eric Scammell，
请在SDK6.0.4查看BLE示例中查看SleepMode示例。如果您不调用中断，设备会再次唤醒，当按下按钮时，调用中断（不是唤醒中断），导致WFI，因此在这种情况下设备未睡眠。请给我更多关于“在OTP之后”的信息，你的目的是什么？
谢谢，
sts_dialog。
嗨sts，
我对芯片已经睡觉的情况并不担心，或者在按下我的按钮时会睡觉。我正在使用wkupct计时器，所以芯片会响应很好。
问题是，在我的App_on_system_powered的实现结束时存在一个非常小的窗口，以及准备睡眠的芯片（在Arch_main.c的行162-168期间）。在该窗口期间，如果调用我的中断，它将设置标志，然后芯片将睡眠。在这种情况下，标志不会被采取行动，直到芯片下一个醒来，这可能是几秒钟。我无法指望交换机中断以结束睡眠状态，因为它将在芯片停止在WFI上之前已清除。
我怀疑最简单的解决方案是从App_Gook_To_Sleep中提出中断如果我看到我的标志，那么WFI立即返回，但我看不到软件的简单方法。
关于OTP，我看到了一些在我的调试环境中不会发生的错误。当我向OTP提交一个程序时，会出现这些错误，此时它们变得非常难以诊断。我怀疑的OTP之前唯一的行为变化会给我的节目问题是睡眠模式，所以我正试图非常小心订购我的操作，以便他们没有被睡眠中断。
你好，我们又见面了，
在唤醒中断的情况下，BLE过程将延迟再次启动（从开头）。在其他情况下，当我之前提到的时，当禁用所有中断并且设备睡眠时，如果例如调用按钮的中断（它将待处理），WFI（将等待中断）并将启动手术开始。请检查是否已将缓冲区的数据放在保留存储器中，否则在睡眠模式下，数据将丢失。
谢谢，
sts_dialog。
你好，
我对代码的解释允许有可能，如果中断在完全错误的时间触发，则为以下事件序列：
1）决定在app_on_system_powered与goto_sleep返回
2）触发中断，并变成待处理
3）中断是服务的
4）禁用中断以准备睡眠模式
5）WFI.
如果发生这种情况，则在WFI处不再是未决的中断。
这对我来说是一个问题，因为我的中断的首选实现要求在中断进行中断后立即调用app_on_system_powered。
我并不担心在app_on_system_powered未发生的行动，因为我的标志处于保留记忆，但它需要在几十或数百毫秒内发生。如果在这种情况下无法依赖逃避睡眠模式，则延迟可能比。
我误认为这可能，或者我没有明确沟通我需要的东西？
你好，
ISR将调用ARCH_FORCE_ACTE_MODE（）函数来停止睡眠模式。此事件设置Sleep_mode = mode_active。在使用标志的位置，将使用ARCH_RESTORE_SLEEP_MODE（）函数。
谢谢，
sts_dialog。