基于JLink的RT Flashloader下载速度优化

NXP管管

基于JLink的RT Flashloader下载速度优化

一、介绍
当客户使用i.MX RT系列的芯片时，不管在调试阶段还是在量产阶段，如果下载到外部NOR Flash的image特别大，那整个下载过程会非常耗时，这大大影响了调试效率或者量产效率。
为了解决这个痛点，本篇应用笔记主要介绍了当使用JLink去下载image时，如何优化Flashloader算法去提升下载速度。


二、Flashloader算法简介
在i.MX RT平台上如果使用JLink去下载image的时候，目前几乎所有的Flashloader都是基于Segger提供的Open Flashloader模型开发的，Segger Flashloader的框架以及开发使用流程,在Segger官网上有详细的介绍，本文简单介绍几点：


2.1. Segger支持用户自行添加目标设备：
Segger支持用户能够自行添加对新设备的支持，不依赖于SEGGER和J-Link软件的版本。


默认情况下，J-Link DLL 带有一个内置设备数据库，该数据库定义了哪些设备名称是已知的。对于已知的设备，SEGGER已经为其提供了默认的烧录下载算法。


但是对于未知的设备，可以通过名为JLinkDevices.xml文件添加其他设备。


打开Segger的安装目录…\Device\NXP\，添加Flashloader算法文件到指定路径，在XML文件中以Segger规定的脚本语法进行添加即可。


如果往XML文件添加已知设备，JLink会优先调用XML文件中的Flashloader算法文件。

1. <Database>
   
2.   <Device>
   
3.     <ChipInfo Vendor="..." Name="..." WorkRAMAddr="..." WorkRAMSize="..." Core="..." />
   
4.     <FlashBankInfo Name="..." BaseAddr="..." MaxSize="..." Loader="..." LoaderType="..." AlwaysPresent="..." />
   
5.   </Device>
   
6. </Database>

复制代码

本文以i.MX RT500和i.MX RT1060平台，SEGGER 7.54d版本为例，来演示如何提升Flashloader的烧录下载速度，因此我在NXP文件夹下添加了全新的iMXRT5xx文件夹和iMXRT106x文件，里面包含了MIMXRT5XX_FLEXSPI.elf文件和MIMXRT106X_FLEXSPI.elf文件，这两个文件就是我优化过后的Flashloader可执行文件，它们可以是.elf文件，也可以是.FLM文件。                                          

2.2. Flashloader算法文件制作平台：
Segger的下载烧录算法文件制作有两种方法：
第一种，使用 Keil uVision IDE，缺点有三：
需要license
没有试用版
仅支持 Cortex-M内核的设备
第二种，使用SEGGER Embedded Studio IDE，有两种优势：
基本上任何在商业范围内使用SEGGER Embedded Studio都需要有效的许可证，但是Open Flashloader是个例外。评估版license就可用于调试和创建 flashloader；不需要有效的license。
支持Cortex-M、Cortex-A/R和RISC-V等多种内核。

2.3 Flashloader算法文件制作方法


SEGGER Embedded Studio提供了Open Flashloader的模板，利用SEGGER Embedded Studio就能生成最终的Flashloader可执行文件。
Flashloader模型有几个重要的API函数构成，如下表所示。这部分API需要用户实现对应MCU设备的flash接口代码，具体到i.MX RT平台上就是基于FLEXSPI外设和NOR FLASH之间的交互代码。

三、影响Flashloader下载速度的因素


本节所有的实验数据都是基于i.MX RT500 EVK板子以及外部NOR Flash(GD25LE64C)展开的。


3.1. 下载时间组成部分:


首先使用Jlink下载器通过Commander窗口往i.MX RT500 EVK板子下载一个2M bytes的image到外部flash，下载结束后能在Commander窗口看到如下log：

简而易见，影响下载速度的因素有如下几个，其中Erase和Program这两个部分耗时占比最大，Compare和Verify耗时占比较小，Prepare和Restore耗时几乎可以忽略，因此优化下载速度的重点是Erase和Program。


3.2. 下载速度相关因素

以4线的QSPI NOR Flash为例，对于Flash的操作主要有读、写、擦这几个部分。下图是NOR Flash的CMD详情。

Read mode对于Flashloader来说影响的是Compare和Verify的效率。



Read的CMD有Read Data，Fast Read，Quad Output Fast Read，Quad I/O Fast Read, Quad I/O Word Fast Read等，区别在MCU和Flash通信过程中发CMD命令是几线，发地址信息是几线，以及数据交互是几线，总结下来有以下这几种模式，一般来说如果是4线的QSPI NOR Flash，推荐用1_4_4 read mode。

EraseCMD除去Chip Erase有三种: Sector Erase，Block Erase(32K)， BlockErase(64K)，Erase模式可以工作在SPI mode，也可以工作在QPI mode，一般工作在SPI mode就行。从擦的效率角度而言，擦除一块很大的区域，采用Block Erase比Sector Erase更有效率的。


ProgramCMD有两种，分别是Page Program和Quad Page Program，一般使用Page Program就行。


影响Flashloader下载效率的因素除了Read mode，Erase mode, Program mode外，另一个重要的因素是Flash的时钟频率，但是这个因素对下载速度的影响是有限的，为了证明这一点做了如下实验。


1）在i.MX RT500 EVK板子上，外部NOR Flash更换为GD25LE64C，在IAR下面去调试一个事先准备好的Flashloader算法，利用MCU的系统时钟来统计擦写时长，擦写的区域为2MB的外部NOR Flash空间。


为了保证实验结果的可对比性，Flash的起始地址一致，2MB的image使用同一份.bin文件。Erase CMD使用的是BlockErase(64K)，Program CMD使用的是Page Program，只改变Flexspi的CLK。


设Flexspi的CLK频率为30M，可以得到如下结果：擦写时长为12.624s。

设Flexspi的CLK频率为100M，可以得到如下结果：擦写时长为12.005s。

因此得到的第一个结论是：Flash的工作频率对于擦写速度影响不大。


2）设Flexspi的CLK频率为100M，只将Program CMD方式从Page Program变为Quad Page Program，其他条件不变，可以得到如下结果：擦写时长为11.952s。

因此得到第二个结论是：Flash的Program模式对于写一个page的整个过程，速度影响不大。


3）通过Flash的datasheet可以找到这款flash的erase，program的typical值。

将理论值，IAR debug测试数据，和JLink Commander测试数据进行比较，可以看到Flashloader算法在IAR中debug是非常接近甚至小于flash手册的typical值，但是当Flashloader算法被Jlink Commander调用时，擦写效率是非常低的。

因此得到的第三个结论是：影响flashloader下载速度的最大瓶颈在于Jlink Commander对于Flashloader算法的调度，或者说是Jlink Commander与运行在MCU端的Flashloader程序之间的交互过程。


3.3. Open Flashloader模型框架
从Flash本身已经找出了影响Flash下载速率的因素，那接下来就要了解Jlink通过SWD/JTAG接口对运行在MCU端的Flashloader的调度过程，具体主要是Compare，Erase，Program，Verify这几个部分。


上文提到，Flashloader可执行文件可以由Keil或者SEGGER Embedded Studio编译生成。但是，Keil的Flashloader模型中Erase和Program函数接口对于下载效率来说是有局限的，因此推荐使用SEGGER Embedded Studio。


SEGGER Embedded Studio提供的Open Flashloader模型提供了SEGGER_OPEN_Program和Program接口，SEGGER_OPEN_Program接口与传统的Program接口相比可以实现更高的吞吐量，如下图所示。

同样，SEGGER Embedded Studio提供的Open Flashloader也提供了SEGGER_OPEN_Erase和Erase接口，这里的Erase接口是用于擦除一个或多个sector区域的。考虑到不同类型的Flash有不同的sector size，因此sector size是用户可配置的。


通过上文分析，擦除一块很大的区域，采用Block擦会比Sector擦更有效率，而Erase接口函数是用户自定义的，所以用户可以将Open Flashloader中提供的sector size当作block size来使用，在底层代码中采用block去擦而不是sector擦，这会是一个提升erase效率的方案。


OpenFlashloader模型还提供了Verify，Read，Erase_Chip等API接口，另外针可以使能TURBO Mode去优化下载算法，这些都是可以优化下载速度的切入点。

四、Flashloader下载速度优化


上一节中主要介绍了影响Flashloader下载速度的因素，以及利用SEGGEREmbedded Studio来优化Open Flashloader模型的一些思路。


本节基于i.MX RT500 EVK板子和i.MX RT1060 EVKB板子来验证提升下载速度的一些优化策略。


为了比较Flashloader算法的优化结果，将i.MX RT500 EVK板子和i.MX RT1060 EVKB板子上的Flash都更换成IS25WP064，下图是IS25WP064的datasheet中关于Erase和Program的理论值。根据Typical值，对2MB的Flash空间进行Sector Erase，Block Erase（64K），Program的典型时长分别为35.84s，4.8s，1.638s，下面会将实验测试数据与理论数据进行比较。


当然，实际用JLink对Flash的下载过程中肯定还有其它操作的时长需要考虑进去。

4.1. 基于i.MX RT500的Flashloader优化
Flashloader可执行文件由SEGGER Embedded Studio或Keil生成，Erase和Program接口分别采用Erase接口和SEGGER_OPEN_Program接口。


IS25WP064的sector size为4KB，page size为256字节。


SEGGER_OPEN_Program可以一次加载多个page到ram中进行缓存，这个数值是可以配置，本实验中将SEGGER_OPEN_Program接口中的一个page大小定义为变量multi_page_size，将Program接口中的一个page大小定义为变量single_page_size，将Erase接口中每次擦的大小定义为变量single_erase_size，将Flexspi的CLK时钟设置为30M。擦的区域为【0x0800 0000，0x0820 0000】，大小为2MB。


经过多次测试，得到如下结果：

有了以上实验数据可以得到下面这几个结论：


SEGGER Embedded Studio生成的Flashloader比Keil生成的Flashloader下载效率更高。


使用Program接口，提高每次加载到RAM的Page Size对下载速度的提升是有限的。


特别需要说明的是Flash的Program或SEGGER_OPEN_Program接口中写Flash是以一个Page为单位的，实验中改变了single_page_size或multi_page_size影响的是JLink往MCU内存中每一次加载缓存的大小，最终底层的Program操作一定是以一个Page为单位的。SEGGER_OPEN_Program接口比Program接口提升的地方在于JLink往MCU内存中每次加载的缓存大小是原来每次加载缓存大小的数倍。


开启TURBO Mode对Flashloader下载速度的提升是显著的，因此推荐用户开启这个功能。


当使用SEGGER_OPEN_Program接口并开启TURBO Mode的情况下，multi_page_size越大，program的速度越快。一般推荐用户将multi_page_size设为4KB。


关于Erase接口，本文没有推荐使用SEGGER_OPEN_Erase接口，因为提升Erase速度的关键在于用Block Erase方案替代SectorErase方案。不过这有一个局限，那就是用户擦的Flash区域足够大（最好是数倍的Block Size），其次下载的Flash起始地址是block size大小对齐的。如果满足不了这两个条件也没关系，解决方案是single_erase_size大小还是采用block size，但在底层Erase驱动中通过算法将被擦的区域拆分成多个block加多个sector的组合，然后分别调用Block_Erase、Sector_Erase底层驱动去操作。


4.2. 基于i.MX RT1060的Flashloader优化
本小节以i.MX RT1060 EVKB板子和外部NOR Flash来测试不同策略下的Flashloader下载速度，i.MX RT1060 EVKB 板子上的默认Flash型号也是IS25WP064。


有了4.1节的结论，本节跳过4.1小节的实验直接拿优化结论进行优化。将Flexspi的时钟设置为30M。擦的区域为【0x6000 0000，0x6080 0000】，大小为8MB。

当使用SEGGER_OPEN_Program接口，开启TURBO Mode，设置multi_page_size为4KB，Erase采用Block Erase方案去擦，下载速度提升是非常显著的。


4.3. Flashloader下载速度优化结果
下表是Flashloader在i.MX RT500 EVK和i.MX RT1060 EVKB的下载速度优化结果，可以看到优化后的下载速度分别是原来没优化过的8.5倍和9.6倍，效果非常明显，实验结果证明优化策略是可行的。

五、结语
Erase和Program的提升已经介绍的很详细了，这里要说明的是Compare和Verify。显然从表中可以看到，Compare和Verify在i.MX RT1060上提升的效率比i.MX RT500还要高很多，影响它们的主要因素是MCU读取Flash数据到内部RAM的性能差异，因为i.MX RT1060是Cortex-M7内核，而i.MX RT500是Cortex-M33内核，i.MX RT1060有32KB、L1级别的 I-cache和D-cache以及主频更高（600M），这对Flash的读取效率会有很大的提升。
另外要说明的是，测试中使用的Flashloader算法能够自动识别并支持大部分NOR Flash，同时也支持所有的i.MX RT平台，该算法用于RT-UFL（RT-UFL 是一个适用全平台 i.MX RT 的通用 Flash 下载算法项目，涵盖绝大部分Flash型号）中，已经得到了广泛验证，参考链接如下：

https://github.com/JayHeng/RT-UFL

阅读全文

eefocus_3883522

您好，请问开发M33内核的下载算法，在实现了init(), erase(), program()相关函数后（这些函数的实现是直接调用的rom secure中的函数）。在调用下载算法时会出现hardfault，SFSR:INVTRAN fault: Invalid transition from secure to normal world，PC位置就是init（），也就是算法刚开始的时候。这个是因为一些什么设置没有设置好吗？
问题二：基于keil开发的算法会时长不稳定，出现PC跑飞的情况，这个您有应对的经验吗？ ****** Error: PC of target system has unexpected value after restoring target. (PC = 0x00000000)!同时，对于问题二不使用loadbin而是直接在keil页面down load对于一些hex文件会在特定的位置出现Flash Timeout. Reset the Target and try it again.这种情况。