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,中的值为0x00010200,可以看到,Header大小0x200已经包含进来。
另外,由于需要使用Python对Application Image进行处理,因此需要在本地安装Python以及相关插件的支持。该操作仅需执行一次。
具体的步骤如下,在Project Tree界面下找到ramcu-toolsMCUbootscripts,鼠标点击右键,Command Window,则会在打开命令行界面,并进入scripts文件夹。键入如下命令,安装Python所需的lib。
pip3 install --user -r scripts/requirements.txt
Python安装所需Lib的提示信息
Python命令中包含e² studio中的Placeholder,针对某个具体的Project,在执行的时候会解析为Workspace下的Project路径以及Project名称。
通过环境变量将Application Project关联起来
打开Application Project的属性界面,在C/C++ Build → Build Variables下添加.bld文件。
添加.bld文件到Application Project的Build Variables
同时,对Application Project Image进行签名操作所需的公钥放在Bootloader中,因此也需要将该文件链接到Application Project中,具体的实现方式如下:
添加Public Key for Sign
注意,此时Public Key for Sign依然位于Bootloader Project所在路径,该配置只是引入该文件的地址,使得在Application Project中调用Python脚本对Image进行签名操作时找到该Public Key。
另外,Image文件的版本信息可以通过添加Environment variable实现,配置方式如下:
将Image版本号添加到Environment variable
最终生成的版本信息会以4字节添加到Header中。
为保证每次Environment variables有变化或者Bootloader生成的***.bld发生改变时,Application Project都可以重新编译,需在Pre-build中增加以下内容:
rm -f ${ProjName}.elf
Pre-build step添加删除***.elf的操作
完成了以上的所有基础配置后,可以编译Application Project。在Console界面查看Build Log,可以发现编译完成后,增加了对Image文件的处理。
对Image签名操作对应的Python内容
此时生成的***.bin.signed文件包含了Header,TLV和Trailer等内容,可以被Bootloader识别并运行。利用工具打开该文件,可以发现它不同于原始的Application Image文件:
.bin.signed文件结构
开始的0x200字节是Header信息,在e² studio中通过Environment variable传入的版本信息1.0.0在0x14地址偏移上。关于其他部分的细节,感兴趣的朋友可自行查阅。
Application Image开始的0x200处,第二个4字节即当前的中断向量表起始地址,可以看到是小端格式的0x00012215,在Primary Slot地址空间(0x00010000~0x87FFF)内。
3调试Application Project
由于芯片上电后需要从0地址(具体地说是0004h地址处)的中断向量开始运行,因此,调试Application Project时需要下载Bootloader 文件,我们在Application Project的Debug Configuration中添加相关部分。
Application Project Debug Configuration Startup选项卡配置
增加对于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向量处,从地址0xa534(低于0x10000)可以判断当前位于Bootloader地址空间范围内。
调试Application Project
点击Load Ancillary按钮,将Application Project Debug文件夹下的***.bin.signed下载到芯片上,注意选择地址为Primary Slot起始地址0x10000。
将1.0.0版本Image ***.bin.signed文件下载到Primary Slot的起始地址0x10000
在memory窗口检查当前Primary Slot中的内容,可以看到Image版本为1.0.0。
Primary Slot中存储了1.0.0版本的Image
点击Resume,可以发现PC指针停在Primary Slot的Application Project Reset向量处,此时PC指针地址0x00012264位于Primary Slot地址空间范围(0x10000~0x87FFF)。如下所示:
PC指针运行在Primary Slot中
再次点击resume,则可以观察到代码运行在Primary Slot的Application Project中。
4升级并验证
由于升级方式是基于应用层面的实现,因此依赖客户的设计。如果需要展示,则建议参考下方链接Application Note中的内容,对应的示例代码包含了遵循XModem协议利用UART传输Image。
RA6 MCU Advanced Secure Bootloader Design using MCUboot and Code Flash Dualbank Mode
在调试状态下,可以通过将待更新的Image文件下载到Secondary Slot中,重启即可使得升级生效。
在Application Project上稍作修改,比如原始的Project在EK-RA6M4上使三个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,目标地址选择0x88000。
将1.1.0版本Image下载到Secondary Slot中
下载成功后查看Memory中的内容,可以确认Secondary Slot存储了1.1.0版本的Image。
Secondary Slot保存了1.1.0版本的Image
按下Reset按钮,使得Bootloader运行,启动代码升级。
可以看到EK-RA6M4从三颗LED闪烁变为仅有一颗蓝色LED闪烁,表明升级成功。
升级完成后查看Secondary Slot对应的Flash已经擦除,Primary Slot中保存了1.1.0版本的Image文件,如下所示。
Primary Slot保存了1.1.0版本的Image,Secondary Slot被擦除
-
编译
+关注
关注
0文章
650浏览量
32797 -
bootloader
+关注
关注
2文章
234浏览量
45529 -
python
+关注
关注
55文章
4778浏览量
84429
原文标题:MCUboot系列(2-2)RA Overwrite模式在FSP中的支持
文章出处:【微信号:瑞萨MCU小百科,微信公众号:瑞萨MCU小百科】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论