亲爱的对话的支持,
在烧毁OTP之前，我需要澄清几点。
背景:我们将使用DA14580 +外部flash(包含2份图像，产品头部和持久性数据)。该设备将一直处于深度睡眠状态，直到它被委托并连接。一旦连接，它将使用扩展睡眠模式。
在我们的应用程序中，引导加载程序将位于OTP中。这意味着当从深度睡眠中醒来时，引导加载程序将首先被镜像，然后引导加载程序将真正的应用程序加载到SysRAM - 2将发生镜像。由于该设备可能会在很长一段时间内不使用，所以即使有2次镜像，它也证明了深度睡眠是合理的。(请确认所描述的预期应用程序是否有效)。
当检测到触摸时，设备需要从深度睡眠中醒来。然而，它需要处理假触摸等，以节省电力。也就是说，在醒来后，它需要读取一个GPIO引脚，并决定是否触摸是假的，如果是，回到深度睡眠;否则做全醒。
问题:
1.如果恢复深度睡眠，最早的检查点(醒来后)在哪里?它可以在system_init()的GPIO_init()之后完成吗?
2.如何为虚假的触摸回到深度睡眠?到目前为止，BLE核心还没有被唤醒，只有MCU在运行。最快的方法是什么?
3.在我们的应用程序中，将产品头部放在OTP和外部flash中的功耗有什么不同吗?
谢谢大家的关注，
uta_lc
设备:
或者更好的是，我们可以在引导加载程序中检查错误触摸，以避免在错误触摸的情况下镜像应用程序映像吗?这里的主要问题是:是否有可能让系统回到深度睡眠模式，如何做到?
嗨uta_lc,
这不是我们曾经尝试或测试所以没有实施计划作为指导,但你的场景似乎是可信的,我想,你可以定制引导装载程序为了进入睡眠和注射用水(),这样你就可以醒来醒来的中断控制器,你可以通过检查580在主while循环中经过的过程来关闭域，检查arch_goto_sleep()， WFI()和arch_resume_from sleep()中的函数。此外，次级引导加载程序是足够小的，代码运行从保留RAM(作为现有分散文件暗示)，所以也许你不需要执行OTP拷贝，并有它所有的时间运行从保留RAM。
由于MT_dialog
谢谢你的最新消息。
避免将引导加载程序从OTP复制到SysRAM是非常好的。然而，我不清楚我们如何才能做到这一点。可以通过在入睡前将REMAP_ADR0设置为retain RAM来实现吗?这意味着以下的安排(需要深度睡眠):
1.双映像引导加载程序(加载用户应用程序)被刻入OTP - SUOTA方案2
2.2份用户图片烧制成外部闪光灯
3.在进入深度睡眠之前，用户应用程序设置了简短的定制引导加载程序(复制到R-RAM中一次)。
4.在被唤醒时，R-RAM引导加载程序将控制并决定是否返回睡眠;
如果需要唤醒，它设置OTP复制和重新映射地址0到系统RAM等，并触发系统复位，这将运行双映像引导加载程序，然后真正的用户应用程序
这工作吗?
嗨uta_lc,
因为我相信上面的实现是相当棘手的，有一些不清楚的部分，例如，让我们说，你有引导加载程序，它跟踪按钮和580复制自定义引导程序从OTP到retram。引导程序正常启动，它将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将启动”。我想我们不用再等100毫秒(14580)了。
谢谢,
uta_lc
嗨uta_lc,
上面的建议是我可以提出的一个可行的方法来实现这种方案，因为，正如我已经提到的，你想要的场景并没有实现，据我所知。可能有方法可以实现这个不用复制每次OTP的定制的引导装载程序和它所有的时间保留内存,为了做到这一点,我认为你必须手动更改每个醒来的手臂寄存器以及其他操作和修改之后,我不知道,因此我们不能提出建议。
在上面的建议中，自定义引导加载程序将位于OTP，并且每次系统醒来时，这个引导加载程序将在retram中复制(据我所知，这是在第一个帖子的设备的初始描述)，这个小启动器将检查按钮按下是否为实际按钮按下，并决定它是否将从系统ram复制相应的图像或进入睡眠模式。我斜面看到如何在每一个唤醒系统将从RETRAM没有重置睡觉时由于手臂寄存器被保留(sysram的系统必须找到相同的图像在睡觉之前,PC SP和手臂寄存器都有程序睡觉前)的值。橄榄球员的位置取决于橄榄球员是如何构建的(二次定制橄榄球员将基于引导装载程序,复制保留内存区域,所以定制引导装载程序会做同样的事情为了离开sysram完好无损,从flash加载图像的一个实际醒来)。因此，为了在唤醒后执行不同的fw，你必须重置设备。
对于Sysram和reram是相同的，这些存储器有不同的地址，reram位于地址0x8000000 - 0x81fff, Sysram位于地址0x20000000到0x2000A7FF。
至于为什么在retram中复制辅助引导加载程序，是因为在从flash复制图像的情况下(当有一个实际的唤醒)，引导加载程序不会在辅助引导加载程序所在的相同位置复制flash图像。
您在数据表上看到的100ms是引导序列的一部分，它是主引导加载程序引入的延迟值，恐怕您将不得不等待，主引导程序必须启动，以便执行OTP拷贝。
由于MT_dialog
感谢MT_dialog的澄清，非常感谢您的耐心。
如果在重置后100ms的延迟是必须的，看起来我们必须放弃上面提到的想法-延迟太长了，31uC的能量消耗太多了。这100毫秒只适用于重置，对吧?我假设OTP复制唤醒后不会有100ms的延迟?
声音我们不得不回到原来的双图像引导加载程序，我们可以把按钮按下检查在双图像引导加载程序和烧伤双图像加载程序直接到OTP。假设使用这个实现可以避免唤醒后的100ms延迟(计划B)?这种设置是否适用于深度睡眠?(我们的应用程序在大多数情况下应该保持深度睡眠，除非用户按下按钮)。
关于从深度睡眠中醒来后的SysRAM映像恢复，我只隐约知道必须做OTP镜像。这是否意味着使用计划B，在唤醒后，引导加载程序镜像到SysRAM(位置20000000)，跳转到它，它将用户fw从flash复制到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停了下来,但是系统ram将是空的或它将有垃圾，所以就我所能告诉你将不能去任何地方，最有可能你将去硬故障，并有你的设备重置。
深度睡眠的标准操作要求用户fw被定位到OTP中，而不是一个二级引导装载程序或任何其他fw。使用深度睡眠时sysram关闭,所以没有手臂的旋翼机运行,因此当醒来控制器触发,OTP被复制到sysram程序简历(此句程序被烧后睡觉前位于sysram醒来OTP以来已完成)。ARM寄存器文件被保留(相同的PC、SP和所有其他寄存器)，因此正在运行的代码可以被正确地恢复。总而言之，当正确使用深度睡眠模式(在OTP中运行fw)时，你不会从flash中加载图像，因此你不会使用辅助引导加载程序。在你的情况中(如果我理解正确的话)你想在每一个醒来的时候加载一个不同的形象,确保按钮被按下,需要一个双重引导装载程序(你不能运行一个不同的图像,当你已经睡不同的代码)。从深度睡眠中醒来并启动的过程与启动是不同的。
如果你用辅助引导加载器烧录OTP，这是将被复制到sysram的fw，而设备在进入睡眠之前正在运行另一个fw。正如我在之前的帖子中提到的，次级引导加载程序运行到保留RAM(你可以从分散文件中检查，甚至下载次级引导加载程序，并在反汇编窗口中检查地址)。矢量表在系统RAM上，一旦辅助引导加载程序开始运行，您应该看到您的PC在靠近0x80000的地址跳转，这是保留RAM的起始地址。这样做是因为当从flash加载时，如果辅助引导加载程序位于sysram中，那么flash中的数据将覆盖辅助引导加载程序的代码。
14583是基于14580年这意味着它有一个OTP,但583年以来一闪,所以在583有一个自定义的OTP引导装载程序从专用靴闪光灯,为了583年开始运行它的OTP引导装载程序的副本,然后引导装载程序应该从flash加载图片,你可以想象,这是耗费时间,所以它是不可行的保持连接间隔设备时必须做所有,为了是percise连接间隔小,能源消耗也使深度睡眠功能不是最佳的583年的情况。
由于MT_dialog