STM32G4 应用程序与 Option Bytes 同时烧录问题

[复制链接]

STMCU小助手发布时间：2022-11-12 17:21

技术帖
文章封面:
文章简介:	STM32G4 应用程序与 Option Bytes 同时烧录问题

1、引言

客户使用 STM32G474 系列芯片，在烧录应用程序的同时要对 Option Bytes 中的 DBANK 进行修改，采用 STlink Utility 或是 CubeProgrammer 工具进行操作，并希望整个过程只用一次烧录动作就完成，发现烧录的应用程序无法运行。

2、问题产生及原因分析

STM32G474 系列芯片具有双 Bank 功能，且默认情况下 Option Bytes 中的 DBANK =1，即双 Bank 使能。但客户实际的应用是单 Bank，所以需要将 DBANK 设置为 0，这样客户在使用 Utility 或是 CubeProgrammer 工具烧录应用程序时，同时设置 Option Bytes 中的DBANK 为 0。但是当烧录结束后，发现应用程序无法正常运行，需要再次烧录才能运行。

整个烧录的过程，在 Utility 中操作如下图所示，通过 Target ->Automatic Mode->Option bytes configuration 对 DBANK 进行修改，在 File 中选择应用程序文件，然后直接烧录。

微信图片_20221112172142.png

在 CubeProgrammer 中操作如下图所示，通过 Erasing & Programming->Automatic Mode->Option bytes commands，写入修改 DBANK 的命令行，在 File 中选择应用程序文件，然后直接烧录。

微信图片_20221112172139.png

整个操作流程是正确的，以 CubeProgrammer 为例，整个操作的日志如下，显示所有操作正常完成。

微信图片_20221112172135.png

但是仔细阅读日志，可以发现整个操作，首先烧录的是应用程序，然后再进行 Option Bytes 的修改，也就是说，在烧录应用程序的时候，MCU 依旧是工作在双 bank 模式下，待程序烧录完成，将双 Bank 修改为单 Bank，注意 DBANK 的修改将会改变 Flash 的取指方式，如下：

• Single bank mode DBANK=0: read access of 128 bits

• Dual bank mode DBANK=1: read access of 64 bits

可以通过单步操作的方式来查看 Flash 中内容的区别。在双 Bank 模式下烧录程序后，读出Flash 内容如下：

微信图片_20221112172114.png

对比以上的内容，可以发现由于取指方式的改变，读取的 Flash 中内容发生了变化，后者出现了大片的空白空间，这也就是此前客户操作方式在完成烧录后程序无法运行的原因。

3、解决方案

通过以上的分析，要实现客户的要求，必须首先对 Option Bytes 进行修改，将 Flash 配置为单 Bank 模式后，才能进行应用程序的烧录，但是在 Utility 或是 CubeProgrammer 中无法修改其本身的操作时序，无法通过一次操作的方式完成，必须分成两步来完成，即：

• 修改 Option Bytes 中的 DBANK
• 烧录应用程序

那么客户最希望的只用一个步骤完成所有的操作是不是没法实现了？别急，ST 还提供了另一个工具，ST_LINK CLI，它的操作完全通过命令行的方式来完成。其路径位于 ST_LINK Utility在安装目录下，如下：

微信图片_20221112172111.png

可以通过 cmd 窗口中直接调用该工具，举个例程如下：

D:\ST-LINK Utility>st-link_cli.exe -c SWD -OB DBANK=0 -Rst -ME -P d:\test.hex -V while_programming

微信图片_20221112172103.png

以上可以看到 Option Bytes 首先完成修改，然后让芯片进行 reset，保证新的 Option Bytes重新加载并生效，最后完成应用程序的烧录。

4、小结
这里分析了客户使用烧录工具 ST Link Utility 和 STM32CubeProgrammer 同时烧录 Option Bytes 中的 DBANK 设置和应用程序后程序无法正常运行的问题，给出了采用 ST-LINK_CLI.exe 工具一次性操作完成 Option Bytes 与应用程序烧录的解决方案。