亲爱的对话支持:
在燃烧OTP之前，我需要澄清几点。
背景:我们将使用DA14580 +外置闪存(包含2份图像、产品标题和持久性数据)。设备将保持深度睡眠状态，直到它被调试和连接。一旦连接，它将使用扩展睡眠模式。
在我们的应用程序中，引导加载程序将位于OTP中。这意味着当从深度睡眠中唤醒时，引导加载程序将首先被镜像，然后引导加载程序将真正的应用程序加载到SysRAM - 2镜像中。由于设备可能在很长一段时间内不启用，因此即使有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设置为保留RAM来完成吗?这意味着以下安排(需要深度睡眠):
1.双映像引导加载程序(加载用户应用程序)被烧成OTP - SUOTA方案2
2.2份用户映像刻录到外部闪存
3.短定制引导加载程序在进入深度睡眠之前由用户应用程序设置(复制到R-RAM一次)。
4.唤醒后，R-RAM引导加载程序将控制并决定是否返回睡眠;
如果需要唤醒，它会设置OTP拷贝并将地址0重新映射到Sys RAM等，并触发系统重置，这将运行双映像引导加载程序，然后运行真正的用户应用程序
这能行吗?
嗨uta_lc,
因为我相信上面的实现是相当棘手的，并且有一些不清楚的部分，例如，假设您有引导加载程序，它跟踪按钮的按下，然后580将自定义引导程序从OTP复制到ream。因此，引导程序正常启动，并将flash映像加载到Sysram，然后映像开始执行。几分钟后，设备没有连接，因此它陷入深度睡眠模式，系统ram断电并清空，但是ARM的寄存器保留，以便代码从停止的地方继续执行。当用户按下按钮时，OTP复制例程将执行，并将复制一个不同于在580上运行的映像。现在我无法想象当ARM开始运行时会发生什么。所以我有一个更简单的建议，我相信这更适合你的场景，你可以做以上所有的事情，当正确的图像开始执行，它的时间去深度睡眠，你可以设置PMU_CTRL_REG的RESET_ON_WAKEUP，当然设置一个gpio，将触发唤醒外部。所以，当按钮被按下时，580，而不是做任何其他事情，它会重置，并将自定义引导程序复制到reram，从那里你可以运行你的自定义引导程序，再次检查按钮，并决定加载哪个图像或返回睡眠。
由于MT_dialog
谢谢你的建议。我不确定我完全理解你的设计:我们的意图是在RERAM中保持非常短的定制引导加载程序，而不必为每个错误唤醒复制它。然而，根据你的评论“所以当按钮被推到580而不是做任何其他事情时，它会重置并将自定义引导加载程序复制到reram，从那里你可以运行自定义引导加载程序”，这是不可能避免复制这个自定义引导加载程序在所有?
如果是这种情况，还需要将定制的引导加载程序复制到RERAM中吗?为什么不把它复制到SysRAM中，然后从那里运行呢?是因为很难运行需要从SysRAM复制第二个引导加载程序的第一个引导加载程序吗?
同样根据数据表，RESET_ON_WAKEUP将“在唤醒后执行硬件重置”。启动程序将启动”。我想我们不必在引导器中再次等待100毫秒(14580)。
谢谢,
uta_lc
嗨uta_lc,
上面的建议是我可以提出的一种可行的方法来实现这种方案，因为，正如我已经提到的，据我所知，你想要的场景并没有实现。可能有方法可以实现这一点，而不必每次从OTP复制自定义引导加载程序，并一直在保留ram中，为了做到这一点，我认为您将不得不在每次唤醒时手动更改ARM寄存器以及我不知道的其他操作和修改，因此我们不能建议。
在上面的建议中，自定义引导加载程序将位于OTP中，每次系统唤醒时，这个引导加载程序将在ream中复制(据我所知，这是第一篇文章中设备的初始描述)，这个小引导程序将检查按钮按下是否为实际按钮按下，并决定它是否将从系统中复制相应的图像或进入睡眠模式。我看不出在每次唤醒中系统将如何从RETRAM运行而无需重置，因为ARM寄存器在休眠时保留(系统必须在睡觉前在系统ram中找到相同的图像，PC, SP和ARM寄存器在睡觉前都具有程序的值)。引导程序的位置取决于引导程序的构建方式(您的自定义引导程序将基于的辅助引导程序被复制到保留ram区域，因此您的自定义引导程序将做同样的事情，以便在实际唤醒的情况下保持系统ram完整并从闪存加载映像)。因此，为了在唤醒后执行不同的fw，您将不得不重置设备。
对于Sysram和ream相同的内存，这些内存具有不同的地址，ream位于地址0x80000-0x81FFF, Sysram位于地址0x20000000到0x2000A7FF。
关于为什么二级引导加载程序在ream中复制，是因为在从flash中复制图像的情况下(当有实际唤醒时)，引导加载程序不会在二级引导加载程序所在的同一位置复制flash图像。
您在数据表上看到的100ms是引导序列的一部分，它是主引导加载程序引入的延迟值，恐怕您将不得不等待，主引导程序必须启动才能执行OTP拷贝。
由于MT_dialog
感谢MT_dialog的澄清-非常感谢您的耐心。
如果复位后必须有100ms的延迟，看起来我们必须放弃上面提到的想法-延迟太长，31uC的能耗太多了。100ms只用于重置，对吗?我假设在OTP副本发生唤醒后不会有100毫秒的延迟?
听起来我们必须回到原来的双映像引导加载程序，我们可以把按钮按下检查在双映像引导加载程序和刻录双映像加载程序直接到OTP。假设这可以避免使用此实现(计划B)唤醒后的100ms延迟?这种设置对深度睡眠有效吗?(我们的应用程序在大多数情况下应该保持深度睡眠，除非用户按下按钮)。
关于从深度睡眠中醒来后的SysRAM镜像恢复，我只模糊地知道必须做OTP镜像。这是否意味着使用计划B，唤醒后，引导加载程序被镜像到SysRAM(位置20000000)，跳转到它，它从flash复制用户fw到SysRAM?如果是这种情况，ARM寄存器(运行用户fw的上下文)何时以及如何恢复?我只能在secondary_bootloader/src/main.c中看到Start_run_user_application函数正在执行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(你可以从分散文件中检查，甚至下载二级引导加载程序，并检查拆卸窗口中的地址)。矢量表位于系统内存上，当辅助引导加载程序开始运行时，您应该看到您的PC跳转到0x80000附近的地址，这是保留RAM的起始地址。这样做是因为当从闪存加载时，如果辅助引导加载程序位于系统内存中，那么来自闪存的数据将覆盖辅助引导加载程序的代码。
14583是基于14580的，这意味着它有一个OTP，但是因为它是583，它也有一个flash，所以在583的OTP中有一个自定义的引导加载程序，从专用的flash启动，为了让583开始运行，它必须为引导加载程序制作OTP副本，然后引导加载程序应该从flash加载图像，你可以想象，这是非常耗时的。因此，当设备必须在较小的连接间隔内完成所有这些操作时，保持连接间隔是不可行的，并且消耗的能量使得深度睡眠功能在583的情况下不是那么理想。
由于MT_dialog