大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是MCUXpresso IDE开发环境下i.MXRT的串行NOR Flash下载算法设计。
在i.MXRT硬件那些事系列之《在串行NOR Flash XIP调试原理》一文中，痞子衡简单提了一下串行NOR Flash下载算法的概念，并没有介绍具体设计细节，关于NOR Flash下载算法每个IDE都有自己的一套设计，虽然基本设计理念是一样的，但是细节方面还是有区别。在前面的文章里，痞子衡分别介绍过《J-Link下算法设计》、《Keil MDK下算法设计》、《IAR EWARM下算法设计》，今天痞子衡就来细聊MCUXpresso IDE下的NOR Flash下载算法：
一、MCUXpresso IDE各版本对i.MXRT的支持
MCUXpresso IDE是飞思卡尔和恩智浦合并之后推出的全新IDE，这个IDE是免费的，可用于新恩智浦全系列ARM Cortex-M控制器（Kinetis、LPC、JN、QN、i.MXRT等）。熟悉这两家公司的人应该知道，其实MCUXpresso IDE就是原恩智浦LPCXpresso IDE与原飞思卡尔Kinetis Design Studio IDE的合体。
从恩智浦官网上看，目前最新的MCUXpresso IDE版本是v11.2.1，其能够支持目前所有已量产的i.MXRT系列。从 MCUXpresso IDE历史各版本Release Note 上看，我们可以看到其各版本对i.MXRT支持情况如下：
各版本下载地址：
https://nxp.flexnetoperations.com/control/frse/product?child_plneID=756637&ver=ARC
MCUXpresso IDE对新MCU型号的支持虽然并不是与自身版本严格绑定，但通过类似打patch的方式比较复杂，且官方不支持这么做，反正这个IDE是免费的，升级又不要钱，也不需要申请license，最好还是通过安装最新版本的方式来实现新型号的支持。
二、为当前MCUXpresso IDE增加新下载算法支持
痞子衡安装的是最新的v11.2.1，我们以为RT600这颗芯片新增flash下载算法为例介绍MCUXpresso IDE下的使用。在开始之前要特别强调一下MCUXpresso IDE与MDK/IAR非常不同的地方，MDK/IAR自带的flash下载算法是跟具体硬件仿真器无关的，它可以在所有支持的仿真器（JLink/DAPLink等）下正常使用，但是MCUXpresso IDE自带的flash下载算法只能在CMSIS-DAP类型的仿真器下使用。如果你在MCUXPresso IDE下使用JLink，那么下载算法只能用JLink的算法。
现在我们随便打开一个i.MXRT600 SDK工程，右击工程进入Properties设置界面，在MCU Settings下可以看到LinkServer Flash Driver的设置界面，这里就是选择flash下载算法。MCUXpresso IDE默认自带了非常多的flash下载算法（文件后缀名是.cfx，其实就是可执行文件elf），即使是同一颗芯片RT600，可以看到其有很多个.cfg可选，这分别对应了不同的flash种类以及与主芯片连接端口。
如果默认选择的Flash下载算法文件不适用你的板子，那么你需要自己提供合适的算法文件(.cfx)，并将其放入MCUXpresso IDE安装目录下(\MCUXpressoIDE_11.2.1_4149\ide\binaries\Flash)，重新打开工程选项，新增的算法会自动刷新到待选算法列表：
三、NOR Flash下载算法设计
MCUXpresso IDE下Flash下载算法是公开的，\MCUXpressoIDE_11.2.1_4149\MCUXpresso_IDE_User_Guide.pdf 文档的 LinkServer Flash Support 章节有一些使用方面的介绍，可以看一下。
3.1 下载算法模板工程
虽然下载算法本身是公开的，但设计文档很少，只给了示例工程。但对于工程师来说，还有什么比给代码来得更直接呢。
示例算法工程路径：\MCUXpressoIDE_11.2.1_4149\ide\Examples\Flashdrivers\NXP\iMXRT
我们就以iMXRT1050_QSPI.zip示例包里代码来分析其结构设计。这个示例包包含两个工程（LPCXFlashDriverLib和iMXRT1050_QSPI），需要先编译LPCXFlashDriverLib工程生成libLPCXFlashDriverLib.a，这个库是iMXRT1050_QSPI工程的源文件，然后编译iMXRT1050_QSPI工程生成我们需要的算法文件MIMXRT1050-EVK_IS25WP064A.cfx。
MCUXpresso IDE下载算法这种两级编译的设计，与IAR/MDK下载算法结构完全不同，这么设计的主要原因是恩智浦ARM Cortex-M内核MCU产品线众多，而MCUXpresso IDE需要支持所有MCU，因此将公共设计的部分提取到了LPCXFlashDriverLib工程里（为了通用性，工程采用CM0指令集来编译）。此外，从工程名你就能看出，还保留着上一代LPCXpresso IDE的基因。
LPCXFlashDriverLib工程有很多build，可以根据ServiceMessages.c文件里的条件编译宏了解到它们的差异，其中Release_SectorHashing工程是默认选择用于最终生成.cfx的，这个build主要是利用32 bit Fowler/Noll/Vo FNV-1a哈希算法对每个Sector的数据下载做了校验。
再到iMXRT1050_QSPI工程，这个工程就是采用具体MCU的内核指令集（CM7）来编译，在工程设置里可以看到链接了LPCXFlashDriverLib工程的Release_SectorHashing生成的.a文件，如果LPCXFlashDriverLib工程选择了其他build，这里也要相应改一下。
3.2 下载算法结构设计
算法本身设计算是几个常用IDE里最复杂的一个了。iMXRT1050_QSPI工程除了一般的FlexSPI驱动外，有两个源文件FlashDev.c和FlashPrg.c，对这文件名有没有很熟悉？是的，这就是标准的CMSIS开源flash算法API定义，里面的内容也是类似的，这里就不赘述了，需要特别强调的是这些Flash擦写API并不是MCUXpresso IDE在下载时实际调用入口。
算法最核心的设计在LPCXFlashDriverLib工程，先看lpcx_flash_memdev.c里内容，这个文件里定义了一个重要的常量结构体MemoryDevice，这个MemoryDevice会被链接在算法执行区域（前64KB的DTCM）的起始位置（0x20000000），给MCUXpresso IDE调试器提供算法全部的信息。
// MemoryDevice Instance (fill it in)
EXTERN_MEMORY_DEVICE
MemoryDeviceMsg_t MemoryDevice =
{
MEM_FLASH_VER2_MAJ+0x0, // Version of flash interface
// Magic number to identify flash driver
// interface
{ 0x01, 0x23, 0x45, 0x00, 0x00, 0x54, 0x32, 0x10 },
(uint32_t)&__load_base, // Driver load address
(uint32_t)&__image_size, // Size of .text and .data
(uint32_t)&__cache, // RAM buffer location
(uint32_t)&__cache_size, // RAM buffer size
(uint32_t)&__initial_sp, // Stack top
(uint32_t)&__stack_size, // Stack size
(uint32_t)&__opmap_val, // Bitmap of available operations - 0 = everything there
&FlashDevice, // Flash Device configuration
ServiceMessages, // Service mailbox flash operation message
0 // Reserved
};MemoryDevice有一个成员是ServiceMessages()函数，这个函数可以说是算法最灵魂的部分了，它才是MCUXpresso IDE调试器调用Flash擦写API的真正入口，调试器通过传入msg参数（所谓Mailbox结构）让算法来执行具体Flash操作并得到执行结果。这种特殊的设计可能也是MCXPpresso IDE算法仅能在CMSIS-DAP类型仿真器下使用的原因吧。
至此，MCUXpresso IDE开发环境下i.MXRT的串行NOR Flash下载算法设计痞子衡便介绍完毕了，掌声在哪里~~~