Thread 中讨论的其他器件：UNIFLASH
工具/软件：
我们目前正在使用的产品 UniFlash 将代码刷写到中 AM2631 。 通常、我们设置 SOP 开关 才能启用 DevBoot 模式 在刷写之前、(SOP0、SOP1、SOP3 = OFF；SOP2 = ON)、在该过程完成后、我们会将所有 SOP 切换为 ON。 该过程可靠运行。
然而、为了简化操作、我们尝试了在不更改 SOP 开关的情况下进行刷写、即让系统处于刷写状态 QSPI (4S)-四路读取模式 。 在此模式下、我们注意到以下行为：
-
刷写可以正常工作 ,但经常 分步执行 、需要第二次尝试。
-
有趣的是、有一些软件版本、例如 B002 、每次闪烁都成功（20 次尝试中的 20 次）。
-
但使用版本 B003 、闪烁 每次第一次尝试时失败 、并且只有在重试后才会成功。
根据我们的理解、当系统处于 QSPI (4S) 模式时、即 QSPI RBL （ROM 引导加载程序）自动运行、加载和执行 SBL 地址。 在此过程中、可能会修改内部寄存器或配置、这可能会干扰刷写过程。
相比之下、 DevBoot 模式 完全跳过 RBL、避免出现任何使其成为的此类副作用 最可靠的选项 刷写模式。
因此、我们要确认：
-
是 DevBoot 模式 在使用 UniFlash 进行刷写时、始终建议使用该工具以避免此类故障？
-
正在闪烁 QSPI (4S) 模式 由于 RBL/SBL 可能会改变芯片状态、因此固有不稳定？
-
鉴于不同版本之间的行为不同（例如，B002 与 B003）、闪烁故障更可能是由以下原因引起的：
-
QSPI 模式导致的引导加载程序干扰？
-
或软件版本本身的具体更改？
-
-
是的,是的 必填 以将 SOP 开关设置为 DevBoot 模式 每次 我们闪存？
-
或者、在某些条件下是否认为可以在不更改 SOP 开关（即在 QSPI 模式下）的情况下闪烁？
-
我们想要确定此问题是与软件相关、还是不将 SOP 设置为 DevBoot 的固有限制。
下面是我们使用的引导模式 PIN 设置的屏幕截图、以及刷写失败时的日志记录。
