前面介绍了MCUboot的基础知识（请查看上方“简介以及在RA FSP上的支持”文章），上次介绍了Overwrite模式（请查看上方“RA Overwrite模式在FSP中的支持”文章），本次着重介绍其中的Swap模式，以及在FSP中如何配置，如Flash怎样划分、安全校验的方式等。
本文以RA4M2 512K Code Flash产品为例，使用Flat mode（不启用TrustZone）说明Swap模式进行升级时的注意事项。
首先回顾一下Swap模式升级的流程。
从代码框架来看，整体划分为三部分，Bootloader，Primary Slot（保存了低版本的User Application v1.0）和Secondary Slot（保存了待更新的高版本User Application v2.0）。
初始状态下，芯片中烧录了Bootloader和Primary Slot，代码从Bootloader处启动，跳转至Primary Slot中的User Application v1.0。在User Application v1.0运行过程中，接收来自外部的更高版本Firmware v2.0，并烧写到Secondary Slot中，烧写完成后，执行软件复位Software reset，代码重新从Bootloader开始运行。此时Bootloader判断Secondary Slot中有待更新的Image，检查其完整性等，校验通过后，将Secondary Slot中的内容和Primary Slot中的内容交换（利用Scratch area作为暂存区域）。然后跳转到Primary Slot中执行。比较升级操作的初始状态和终止状态，发现Primary Slot中运行的代码从低版本的v1.0变为高版本的v2.0。
在e2 studio中进行开发时，Bootloader和User Application为相互独立的Project，但位于同一个Workspace中。先Build Bootloader Project，然后Build位于Primary Slot的User Application Project，由于Bootloader规定了对于整个存储空间的划分，同时包含了对User Application Image进行签名/验签所用的密钥，因此Application Project会依据Bootloader build输出的Bootloader Data File代替原有的Linker Script File（链接脚本文件）进行link，并利用Bootloader包含的密钥进行Image映像文件的处理。
1 新建Bootloader并配置MCUboot参数
由于Bootloader是整个系统的关键，因此我们第一步创建Bootloader Project并配置一些关键选项如Flash Layout和加密算法等。
对于Bootloader Project，可以在e2 studio中新建并命名。在FSP的Stack选项卡下，点击New Stack → Bootloader → MCUboot，即可将该功能添加进来。
添加MCUboot之后，由于它依赖一些底层驱动，如Flash，Crypto等，因此会在初始界面提示错误，按照提示信息逐个修复即可，此处不详细展开。
注意，如需使用示例密钥对Application Image进行处理，则需要添加MCUboot Example Keys。该Key仅供测试使用，量产时需进行替换。
假如使用Crypto相关的driver，则参考下图的配置修复相关error。
将所有的错误修正后，配置MCUboot的关键属性。
展开Common选项下的General属性，对于几个可配置的关键选项，说明如下:
升级模式Upgrade Mode，可以从Overwrite，Swap和Direct XIP中选择，此次选择Swap。该选项是决定Bootloader大小的关键性因素，Overwrite模式最小，Swap模式最大。
Validate Primary Image，建议设定为Enabled，除非资源非常紧张，开启这部分功能带来的代码量增加不过几十字节而已。
Downgrade Prevention (Overwrite Only)，由于该选项仅在Overwrite模式可选，因此设定为Disabled。
展开Common选项下的Signing and Encryption Options属性，对于几个可配置的关键选项，说明如下：
签名类型Signature Type，规定了对于Application Image进行签名所用的方式，可从None，ECDSA P-256，RSA 2048，RSA 3072四项中任选其一。假如使能签名，则代码量最小的是ECDSA P-256
Custom可以从--confirm和--pad两者中任选其一
- 默认选项为--confirm，在对Image进行签名操作时，会将该Image做标记，Bootloader判断时会将Secondary Slot和Primary Slot交换。下次复位时，两个Slot不会交换。
- 设定为--pad时，签名操作会将Image的Trailer部分标记为“可考虑使用该Image升级”。将Image写入Secondary Slot之后，Bootloader会先将Secondary Slot和Primary Slot进行交换，使得Secondary Slot中的Image得到一次执行的机会。在执行的过程中，假如调用了boot_set_confirmed()函数，则下次复位后，不执行Swap。假如在执行的过程中，并没有调用boot_set_confirmed()函数，则下次复位后，继续执行Swap，代码回到旧版本的Image。这是实现代码回滚的一种方式，我们会在下一篇文章中做详细介绍。
Encryption Scheme，根据对于Application Image是否加密进行设定。默认是Disabled，假如使能，则可以从ECIES-P256和RSA-OAEP (RSA 2048 only)中任选其一。Encryption Enabled情况下，Bootloader代码量会明显增加。
接下来配置Flash Layout
对于Flash Layout来说，由于升级模式已锁定Swap，在此基础上决定Bootloader的大小因素就只剩下校验算法的选择了。
由于Bootloader占据从0地址开始的空间，而RA4M2在低地址上的8个block大小均为8KB，因此我们先将Bootloader大小设定为64KB，即0x10000。Swap模式需要保留一个Block大小（32K）的空间用于对两个Slot内容进行交换，因此还剩512 – 8*8 – 32 = 416KB。假如将这416KB等分，则208K无法被32K整除，因此只能等分Block 8～Block 19，Primary Slot和Secondary Slot各占6个Block （32KB）。
既然如此，我们索性把Bootloader设定为96KB（Block 0～8），即0x18000。Primary Slot占据6个Block （Block 9～14），Secondary Slot占据6个Block （Block 15～20），最高地址的Block 21作为Swap模式下的Scratch area。
Bootloader Flash Area Size (Bytes)：
设定为0x18000即可
Image 1 Header Size (Bytes)：
前面的划分Primary Slot和Secondary Slot包含Header，对于Cortex-M33内核的产品，有中断向量表对齐的要求，因此我们建议将Header size统一设定为0x200，以支持Application的所有中断。
Image 1 Flash Area Size (Bytes)：
根据前面的计算结果，填入0x30000（6个32K block）
Scratch Area用于暂存两个Slot内容交换时的最小单元，因此我们将Scratch Area大小设定为Block size 0x8000（32K）。
至此，对于Bootloader的配置已经完成了。
接下来我们需要在hal_entry.c中增加对函数mcuboot_quick_setup()的调用。在e2 studio界面下，Project Explorer中找到Developer Assistance找到Call Quick Setup，鼠标左键点选，保持左键按下的状态，拖动到hal_entry.c文件的hal_entry()函数定义之前。
然后在hal_entry()入口处增加对函数mcuboot_quick_setup的调用。
Build Project可以顺利完成，提示“0 errors, 0 warnings”。在Debug文件夹下确认包含同名的***.bld文件，用文本编辑器打开，检查内容。
.bld文件是XML格式的，主要包含两部分：
第一部分是symbol，主要是Bootloader对Flash Layout的设定，FLASH_IMAGE_START值为0x00018200，即位于Primary Slot的Application Project实际Link（链接）地址。FLASH_IMAGE_LENGTH值为0x0002FE00，即Primary Slot大小（0x30000）减掉Header Size（0x200）。
第二部分是对Application Image进行签名所用到的Python命令，该命令的输入是Application Project Build生成的原始Binary（二进制）文件，输出是同名的签名后的文件，后缀是.bin.signed。同时传入的参数还有文件版本，签名所用的密钥等。由于RA4M2搭载了支持TrustZone的Cortex-M33内核，因此文件的结构包含了对TrustZone的支持。对于不启用TrustZone的应用场景，我们仅需关注Python命令的第一部分。
2 将Application Project和Bootloader关联起来
接下来，我们要利用该Bootloader调试目标Application Project，如何才能将Bootloader和Application关联起来呢？就需要借助刚才提到的Bootloader Project Build所生成的***.bld文件。
除了新建Project，也可以将任意一个现有的Project跟Bootloader关联起来，此时，该Project编译的地址为Primary Slot起始地址加上Header大小。
Application Project会利用.bld中的内容替代原始的链接脚本文件（linker script file）。编译的起始地址来自标号FLASH_IMAGE_START，图中的值为0x00018200，可以看到，Header大小0x200已经包含进来。
另外，由于需要使用Python对Application Image进行处理，因此需要在本地安装Python以及相关插件的支持。该操作仅需执行一次。
具体的步骤如下，在Project Tree界面下找到ra\mcu-tools\MCUboot\scripts，鼠标点击右键，Command Window，则会在打开命令行界面，并进入scripts文件夹。键入如下命令，安装Python所需的lib。
pip3 install --user -r scripts/requirements.txt
Python命令中包含e2 studio中的Placeholder，针对某个具体的Project，在执行的时候会解析为Workspace下的Project路径以及Project名称。
通过环境变量将Application Project关联起来
打开Application Project的属性界面，在C/C++ Build → Build Variables下添加.bld文件。
同时，对Application Project Image进行签名操作所需的公钥放在Bootloader中，因此也需要将该文件链接到Application Project中，具体的实现方式如下：
注意，此时Public Key for Sign依然位于Bootloader Project所在路径，该配置只是引入该文件的地址，使得在Application Project中调用Python脚本对Image进行签名操作时找到该Public Key。
另外，Image文件的版本信息可以通过添加Environment variable实现，配置方式如下：
最终生成的版本信息会以4字节添加到Header中。
为保证每次Environment variables有变化或者Bootloader生成的***.bld发生改变时，Application Project都可以重新编译，需在Pre-build中增加以下内容：
rm -f ${ProjName}.elf
完成了以上的所有基础配置后，可以编译Application Project。在Console界面查看Build Log，可以发现编译完成后，增加了对Image文件的处理。
此时生成的***.bin.signed文件包含了Header，TLV和Trailer等内容，可以被Bootloader识别并运行。利用工具打开该文件，可以发现它不同于原始的Application Image文件：
开始的0x200字节是Header信息，在e2 studio中通过Environment variable传入的版本信息1.0.0在0x14地址偏移上。关于其他部分的细节，感兴趣的朋友可自行查阅。
Application Image开始的0x200处，第二个4字节即当前的中断向量表起始地址，可以看到是小端格式的0x00018ab9，在Primary Slot地址空间（0x00018000～0x87FFF）内。
3 调试Application Project
由于芯片上电后需要从0地址（具体地说是0004h地址处）的中断向量开始运行，因此，调试Application Project时需要下载Bootloader文件，我们在Application Project的Debug Configuration中添加相关部分。
增加对于Bootloader的加载，类型选项设定为Image and Symbols，这样调试状态下可以跟踪Bootloader中代码运行的状态。
同时，将Application Project对应的***.elf → Load type设定为Symbols only，仅下载标号。由于加载了Application Project对应的symbol，因此我们可以调试时检查代码的运行状态。但实际下载到code flash的内容是经过了Python脚本处理，增加了Header，TLV和Trailer等信息的***.bin.signed文件，因此可以通过Bootloader的安全校验。
按下Debug按钮，启动调试，此时可以发现PC停在Bootloader的reset向量处。
点击Load Ancillary按钮
，将Application Project Debug文件夹下的***.bin.signed下载到芯片上，注意选择地址为Primary Slot起始地址0x18000。
在memory窗口检查当前Primary Slot中的内容，可以看到Image版本为1.0.0。
点击Resume，可以发现PC指针停在Primary Slot的Application Project Reset向量处，此时PC指针地址0x00018ab8位于Primary Slot地址空间范围（0x18000～0x37FFF）。如下图所示。
之后在任意时刻暂停，通过PC指针的地址空间范围和对应的代码标号可以发现PC已经运行在Application Project中了。
再次点击resume，则可以观察到代码运行在Primary Slot的Application Project中。
4 升级并验证
由于升级方式是基于应用层面的实现，因此依赖客户的设计。如果需要展示，则建议参考下方链接Application Note中的内容，对应的示例代码包含了遵循XModem协议利用UART传输Image。
RA6 MCU Advanced Secure Bootloader Design using MCUboot and Code Flash Dualbank Mode：https://www.renesas.com/us/en/document/apn/ra6-mcu-advanced-secure-bootloader-design-using-mcuboot-and-code-flash-dualbank-mode
在调试状态下，可以通过将待更新的Image文件下载到Secondary Slot中，重启即可使得升级生效。
在Application Project上稍作修改，比如原始的Project在EK-RA4M3上使三个LED（红绿蓝）一起闪烁，而我们将代码更新为只有一个LED（蓝色）闪烁。同时，将Image Version从1.0.0更改为1.1.0，重新Build Project，确认Debug文件夹下的.bin.signed重新生成了。
现在将1.1.0版本的Image烧录到Secondary Slot中，点击Load Ancillary，选中***.bin.signed，目标地址选择0x48000。
下载成功后查看Memory中的内容，可以确认Secondary Slot存储了1.1.0版本的Image。
按下Reset按钮
，使得Bootloader运行，启动代码升级。
可以看到EK-RA4M3从三颗LED闪烁变为仅有一颗蓝色LED闪烁，表明升级成功。
升级完成后查看Primary Slot和Secondary Slot，发现两个Slot内容已经交换了。Primary Slot中保存了1.1.0版本的Image文件，而Secondary Slot中保存了1.0.0版本的Image文件，如下图所示。
一、接受条款 使用者（也称"您"）在访问或使用本网站及其服务时，即已经表示同意并不加修改地接受本《用户协议》、本网站的《隐私声明》、《法律声明》以及其关或相链接的网页和网站的条件和条款的规定。我们强烈建议：在您阅读和接受本《用户协议》时，也应阅读并接受本《用户协议》中所提到《隐私声明》、《法律声明》及其相关或相链接网页或网站所包含的资料，因为《隐私声明》、《法律声明》及其它相关网页或网站可能包含对您适用的进一步规定。（请注意：点击划有底线的词句即可链接到上述《隐私声明》、《法律声明》及其它相关或相链接的网页和网站。
二、使用者的资格要求 在本网站中"使用者"指的是浏览、阅读、使用本网站信息或服务的任何个人或组织。本网站的服务仅适用于根据相关法律的规定具有签订有约束力的合同的个人或组织并仅由其使用。本网站的服务不向18周岁以下的个人使用者提供，也不向临时被本网站中止或取消使用者资格的使用者提供。如果使用者不符合本条规定，请停止使用本网站或本网站的服务。
RA生态工作室网站由欣瑞利科技运营
地址：深圳市南山区西丽TCL科学园E2-5C
邮箱：common@ramcu.cn
RA生态工作室
瑞萨嵌入式小百科
样品
应用
微信