痞子衡嵌入式：MCUBootUtility v2.3.1发布，解决了长久以来非空flash可能无法下载的问题

--
　　痞子衡维护的NXP-MCUBootUtility工具距离上一个版本(v2.3)发布过去3个月了，这一次痞子衡为大家带来了小版本升级v2.3.1（第一次做x.y.z中z级别更新），这个版本主要有两个比较重要的改动需要跟大家特别说明一下。

一、v2.3.1更新记录

二、两个不可忽视的更新

> 改进: 在使用Flashloader里擦除操作时，某些情况下需要先检查目标区域是否为空
> 修复: 当连接得到的flash Page/Sector/Block Size信息有误时，无法做进一步下载

2.1 确定指定Flash区域为非空后再擦

　　我们知道，工具对于i.MXRT1xxx系列开发板的外挂Flash擦写支持是通过加载二级Flashloader来实现的，而Flashloader来自于SDK包中的\boards\evkimxrt1xxx\bootloader_examples\flashloader工程。

　　Flashloader中集成了完整的FlexSPI NOR Flash驱动，对于擦除操作，我们知道很多Flash都同时支持4KB和64KB擦除粒度，因为Flashloader是因i.MXRT芯片而异的，每个芯片的具体Flashloader对于擦除的处理不尽相同，目前主要有两个策略：

策略1：永远用64KB的粒度去做擦除。

策略2：混合使用4KB和64KB的粒度来做擦除，大区域先用64KB，到小区域再用4KB细化。

　　对于工具v1.1及之前版本，这两种策略的Flashloader配合工具使用都不会有问题。但是从v1.2开始，工具配合使用策略1的Flashloader会有一些问题。目前已知RT1050在HAB加密模式下，一键下载App后去回读会发现偏移0x2000之后本该是App的地方全是0xFF，没能正确下载，原因是工具流程里会在下载完App之后写一次FDCB，而做擦除时因为粒度是64KB，所以误擦了已下载的App。

　　因此v2.3.1里的解决方案是，先判断FDCB区域是否为全0xFF，如果是的话，就不做擦除了，直接写FDCB。这个不是完美的解决方案，最好的方案还是修改Flashloader去使用策略2的擦除方法。

2.2 不依赖读回的Page/Sector/Block信息去下载

　　工具在一键下载前首先需要连接上主芯片，在连接过程中会在左下角芯片状态窗口显示Flash的Page/Sector/Block信息，这个信息是从哪里来的呢？不同的情况下来源不同：

情况1：如果当前Flash是全空的（或者没有FDCB），那么Flashloader会读取Flash中的SFDP表，根据SFDP表中的信息（包含Page/Sector/Block Size）自动生成用于启动的512bytes的FDCB写入Flash的起始地址处，并在软件界面同步显示。

情况2：如果Flash中已有FDCB（这个FDCB可能来自于SDK里的启动头，也可能是Flashloader读SFDP表生成的），那么Flashloader便会复用这个信息，不再重新写入FDCB。

　　对于情况2中的FDCB来自于SDK里的启动头，如果启动头中没有填充有效的Page/Sector/Block Size信息，那么在工具窗口你会看到Page/Sector/Block Size = 0x0/0xFFFFFFFF的情况下，在这种情况下工具无法再进行后续下载，因为v2.3之前工具会用Page/Sector Size对擦除或烧写的长度做对齐，显然无法用0x0/0xFFFFFFFF做有效的对齐。

　　v2.3.1做了改进，不再强制用Page/Sector Size对擦除或烧写的长度做对齐，因为Flashloader里本身就对传入的区域参数做了对齐处理。

　　至此，这次更新的主要特性便介绍完了。MCUBootUtility项目地址如下。虽然当前版本（v2.3.1）功能已经非常完备，你还是可以在此基础上再添加自己想要的功能。如此神器，还不快快去下载试用？