亲爱的对话的支持,
在烧OTP之前，我需要澄清几点。
背景:我们将使用DA14580 +外部闪存(包含2份图像，产品头和持久性数据)。在调试和连接之前，设备将一直处于深度睡眠状态。一旦连接，它将使用延长睡眠模式。
在我们的应用程序中，引导加载程序将位于OTP中。这意味着当从深度睡眠中醒来时，引导加载程序将首先被镜像，然后引导加载程序将真正的应用程序加载到SysRAM - 2中将发生镜像。由于设备可能会在很长一段时间内处于未调试状态，因此即使经过两次镜像，也可以进行深度睡眠。(请确认所描述的申请是否有效)。
当检测到触摸时，设备需要从深度睡眠中唤醒。然而，它需要处理假触摸等，以节省电力。也就是说，在唤醒后，它需要读取一个GPIO引脚，并决定是否触摸是假的，如果是，就返回深度睡眠;否则做全醒。
问题:
1.(醒来后)检查是否回到深度睡眠的最早时间是什么时候?是否可以在system_init()中的GPIO_init()之后进行?
2.如何为虚假的触碰恢复深度睡眠?到目前为止，BLE核心还没有被唤醒，只有MCU醒了。最快的方法是什么?
3.在我们的应用程序中，将产品标头放在OTP中与放在外部闪存中在功耗方面有什么区别吗?
谢谢大家，
uta_lc
设备:
或者更好的是，我们能否在引导加载程序中检查假触摸，以避免在假触摸的情况下镜像应用程序映像?这里的主要问题是:是否有可能将系统恢复到深度睡眠模式，如何恢复?
嗨uta_lc,
这不是我们曾经尝试或测试所以没有实施计划作为指导,但你的场景似乎是可信的,我想,你可以定制引导装载程序为了进入睡眠和注射用水(),这样你就可以醒来醒来的中断控制器,可以关闭该域通过检查程序,580年主要的while循环,经过检查的功能arch_goto_sleep(),注射用水()和arch_resume_from睡眠()。此外，辅助引导加载程序足够小，代码从保留RAM中运行(正如现有的scatterfile所暗示的那样)，因此可能根本不需要执行OTP拷贝，而让它一直从保留RAM中运行。
由于MT_dialog
谢谢你的更新。
避免将引导加载程序从OTP复制到SysRAM将是非常好的。然而，我不清楚我们如何才能做到这一点。是否可以在睡觉前将REMAP_ADR0设置为Retention RAM ?这意味着以下安排(需要深度睡眠):
1.双映像引导加载程序(用于加载用户app)刻录到OTP - SUOTA方案2中
2.2份用户图像刻录到外部闪存
3.短的定制引导加载程序在进入深度睡眠之前由用户应用程序设置(复制到R-RAM一次)。
4.醒来后，R-RAM引导加载程序将控制并决定是否返回睡眠;
如果需要唤醒，它设置OTP拷贝，并将地址0重映射到Sys RAM等，并触发系统重置，这将运行双映像引导加载程序，然后是真正的用户应用程序
这工作吗?
嗨uta_lc,
因为我相信，上面的实现是相当棘手的，有一些不清楚的部分，例如，让我们说，你有引导加载程序，它跟踪一个按钮的推动和580从OTP复制自定义引导程序到重定向。引导程序正常启动，它将flash图像加载到Sysram，然后图像开始执行。几分钟后，设备没有连接，因此它进入深度睡眠模式，系统ram关闭，空了，但ARM的寄存器保留下来，以便代码从停止的地方继续执行。当用户按下按钮时，OTP拷贝例程将执行，并将复制一个不同于以前在580上运行的图像。现在我无法想象当ARM开始运行时会发生什么。所以我有一个更简单的建议，我相信更适合你的场景，你可以做以上所有的，当适当的映像开始执行，它的时间进入深度睡眠，你可以设置PMU_CTRL_REG的RESET_ON_WAKEUP，当然，设置一个gpio，将触发外部唤醒。所以当按钮被按下580，而不是做任何其他事情，它会重置，并将自定义引导加载程序复制到Retram，从那里你可以运行自定义引导加载程序，并再次检查按钮，并决定加载或返回睡眠。
由于MT_dialog
谢谢你的建议。我不确定我是否完全理解了您的设计:我们的意图是在RERAM中保留非常短的定制引导加载程序，而不必为每次错误唤醒复制它。然而，根据你的评论“所以当按钮被按下580而不是做任何其他事情时，它将重置，并将复制自定义引导加载程序到Retram，从那里你可以运行自定义引导加载程序”，这是不可能避免复制这个自定义引导加载程序在所有?
如果是这种情况，还需要将定制的引导加载程序复制到RERAM中吗?为什么不直接把它复制到SysRAM中然后从那里运行呢?是因为很难运行第一个引导加载程序，需要从SysRAM复制第二个引导加载程序吗?
同样根据数据表，RESET_ON_WAKEUP将“在唤醒后执行硬件重置。Booter将启动”。我想我们不会再在靴子里等待100ms(14580)了吧?
谢谢,
uta_lc
嗨uta_lc,
上面的建议是我可以提出的一个可行的方法来实施这种方案，因为，正如我已经提到的，据我所知，你想要的场景并没有实现。可能有方法可以实现这一点，而不必每次从OTP复制自定义引导加载程序，并一直在保留ram中，为了做到这一点，我认为你将不得不在每次唤醒时手动更改ARM寄存器，以及其他我不知道的操作和修改，因此我们不能建议。
在上面的建议中，自定义引导加载程序将位于OTP中，每次系统唤醒这个引导加载程序将在重定向中复制(据我所知，这是在第一篇文章中对设备的初始描述)，这个小引导程序将检查按钮按下是否是一个实际的按钮按下，并决定它是否将从系统ram复制相应的图像或进入睡眠模式。我不知道如何在每次唤醒系统将运行从RETRAM没有重置，因为ARM寄存器在睡觉时被保留(系统必须在睡觉前在系统ram中找到相同的图像，PC, SP和ARM寄存器将在睡觉前都有程序的值)。引导程序的位置取决于引导程序是如何构建的(您的自定义引导程序将基于的辅助引导加载程序被复制到保留ram区域，因此您的自定义引导加载程序将做同样的事情，以保持系统ram完好无损，并在实际唤醒的情况下从闪存加载图像)。因此，为了在唤醒后执行不同的fw，您将不得不重置设备。
当系统ram和重传存储器相同时，它们的地址不同，重传存储器位于地址0x80000-0x81FFF之间，系统存储器位于地址0x20000000到0x2000A7FF之间。
关于为什么二级引导加载程序以重传方式复制，是因为在从flash复制图像的情况下(当有一个实际的唤醒)，引导加载程序不会在二级引导加载程序所在的相同位置复制flash图像。
您在数据表上看到的100ms是引导序列的一部分，它是主引导加载程序引入的延迟值，恐怕您将不得不等待，为了执行OTP拷贝，主引导程序必须启动。
由于MT_dialog
感谢MT_dialog的澄清-非常感谢您的耐心。
如果重置后100ms的延迟是必须的，看起来我们必须放弃上面提到的想法-延迟太长了，31uC的能耗太大了。100ms只适用于重置，对吧?我假设在OTP拷贝发生唤醒后不会有100ms的延迟?
听起来我们必须回到原来的双映像引导加载程序，我们可以把按钮按检查在双映像引导加载程序，并将双映像加载程序直接烧录到OTP。假设这可以避免使用此实现(B计划)唤醒后的100ms延迟?这种设置对深度睡眠有效吗?(我们的应用程序在大多数情况下应该保持深度睡眠，除非用户按下按钮)。
关于从深度睡眠中醒来后恢复SysRAM映像，我只模糊地知道必须要做OTP镜像。这是否意味着使用B计划，在唤醒后，引导加载程序被镜像到SysRAM(位置20000000)，跳转到它，它从flash复制用户fw到SysRAM?如果是这种情况，什么时候以及如何恢复ARM寄存器(用户fw的运行上下文)?我只能看到Start_run_user_application函数在secondary_bootloader/src/main.c正在执行sw_reset，这是否意味着每次醒来(从深度睡眠)都做了一个新的引导?(这听起来当然不对，但背后的故事是什么?这里有医生吗?如果没有，请在这里解释一下。)
还有一个关于深度睡眠的一般性问题(请原谅我——在时间和金钱方面，我们不能在许多芯片上消耗OTP并尝试，这就是为什么我在这么做之前问了很多问题):我知道使用深度睡眠的最佳方案是完全避免次要引导加载程序——在这种情况下，只需要OTP镜像就可以完全恢复SysRAM映像。通过引入上述双映像引导加载程序，从深度睡眠中恢复是一个漫长的过程，并且只对非常长的连接间隔有用。这就是为什么14583根本不提供深度睡眠模式的原因吗?如果不是，那是什么?
问候,uta_lc
嗨uta_lc,
是的，100ms是主引导加载程序的一部分，BootROM代码只会在系统上电或发生硬件重置时执行。从深度睡眠的唤醒序列是不同的路径，由硬件FSM执行，而不是像上电时那样由SW执行。
关于你提到的B计划，我不太明白它的功能，据我所知，二级引导加载程序将在OTP中，当一个按钮被按下时，二级引导加载程序将检测到按钮被按下并加载实际图像，当没有与设备交互，设备进入深度睡眠而醒来时没有重置，会发生什么?如果设备检测到唤醒信号已经发生，它将执行一个OTP拷贝，自定义引导加载程序将在ret ram中，HW FSM将触发，拷贝已经完成，并将启动ARM。但是手臂寄存器值被保留,所以手臂会开始执行一个新的代码位于其他位置与PC和SP和所有其他寄存器值的代码运行在睡觉之前,所以它将试图找到代码从PC因此sysram停了下来,但sysram将是空的或者它会有垃圾,我能告诉你不能去任何地方,很可能你将去hardfault设备重置。
深度睡眠的标准操作要求用户fw位于OTP中，而不是次要引导加载程序或任何其他fw。当使用深度睡眠时，系统ram被关闭，因此没有fw供ARM运行，因此当唤醒控制器触发时，OTP被复制到系统ram，程序恢复(在进入睡眠前被烧毁的同一个程序在OTP完成后被唤醒后位于系统ram中)。ARM寄存器文件被保留(相同的PC、SP和所有其他寄存器)，因此可以正确地恢复正在运行的代码。综上所述，当正确使用深度睡眠模式(在OTP中运行fw)时，你不会从flash加载图像，因此你不会使用辅助引导加载程序。在你的情况下(如果我理解正确)，你想在每次醒来加载一个不同的图像，并确保按钮被按下，这需要一个双重引导加载程序(你不能运行一个不同的图像，当你已经通过不同的代码睡觉)。从深度睡眠中醒来和充电的过程与开机是不同的。
如果您使用辅助引导加载程序烧录OTP，那么当设备在进入睡眠状态之前运行不同的fw时，该fw将被复制到系统ram中。正如我在前一篇文章中提到的，辅助引导加载程序运行到保留RAM(你可以从分散文件中检查，甚至下载辅助引导加载程序并在反汇编窗口中检查地址)。矢量表在系统RAM上，一旦辅助引导加载程序开始运行，您应该会看到您的PC跳到0x80000附近的地址，这是保留RAM的起始地址。这样做是因为当从flash加载时，如果辅助引导加载程序位于系统ram中，那么来自flash的数据将覆盖辅助引导加载程序的代码。
14583基于14580这意味着它有一个OTP，但因为它是一个583它也有一个闪光灯，所以在583的OTP中有一个自定义引导加载程序从专用闪光灯引导，为了让583开始运行它必须为引导加载程序制作OTP副本然后引导加载程序应该从闪光灯加载图像，你可以想象，这是很耗时的，所以保持连接间隔是不可行的，当设备必须做所有这些，以在一个小的连接间隔精确，而且能量消耗使深度睡眠功能在583的情况下不是最优的。
由于MT_dialog