物联网的不断扩展，推动了新一轮大规模的智能化升级浪潮。智能化正在从云端向具有机器学习（ML）能力的边缘设备转移，这些设备能够在本地处理传感器数据流，与基于云的AI系统相比，延迟更低，安全性更高，提供更好的用户隐私保护。为了将边缘设备从单纯的数据采集转换为具有自主操作能力的边缘智能，开发人员需要具有多核性能并内置加速器的新型低功耗微控制器（MCU）来执行ML任务，同时最小化功耗预算以保持节能的系统设计。 

本人很久以前写过一篇文章 《ARM Cortex-M镜像文件(.bin/.hex/.s19)》，详细介绍了三种流行的镜像文件格式，这些镜像文件不同于可执行文件(.elf)，它们主要保存的是芯片能够执行的二进制机器码数据，以及辅助的地址信息和校验和，其他像 .elf 文件里有的工程信息、代码信息、调试信息全部被去除了，说白了镜像文件主要是为最终量产过程而生的。

一般情况下，在 IDE 开发环境里编译链接生成的是可执行文件，然后可以在工程选项做一些设置能进一步生成镜像文件。不同 IDE 下生成镜像文件的方法不同，今天主要介绍来MCUXpresso IDE下生成镜像文件的方法以及与 IAR/MDK 的对比。

注：本文测试的MCUXpresso IDE版本是v11.6.0_8187。

一、各种IDE下生成镜像文件的方法

我们先来看看MCUXpress以外的其它IDE下是如何生成各种格式镜像文件的。我们以 \SDK_2.11.1_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\hello_world\cm7 目录下的工程文件为例。

1.1 IAR EWARM下

编译hello_world_demo_cm7.eww工程（随便选择 debug build），会在工程目录 debug文件夹下生成可执行文件hello_world_demo_cm7.out。如果在工程选项Output Converter里开启Generate additional output，则可以指定生成想要的镜像文件(bin/hex/srec)。

如果你仔细看Build窗口的log信息，会发现IDE其实是在可执行文件生成之后，再借助 \IAR Systems\Embedded Workbench 9.10.2\arm\bin\ielftool.exe 小工具对可执行文件做的二次转换生成的镜像文件。

ielftool.exe --bin  app.out app.binielftool.exe --ihex app.out app.hexielftool.exe --srec app.out app.s19

所以其实在工程选项Build Actions里的Post-build command line添加如下调用 ielftool.exe做转换的命令（CMD /C 的意思是以 bat 文件内容方式打开后面的命令；命令需要用双引号括起来；路径也需要单独用双引号括起来，防止路径中存在空格，导致命令出错），也能达到一样的效果。

CMD /C ""$TOOLKIT_DIR$\bin\ielftool.exe" --bin "$PROJ_DIR$/debug/hello_world_demo_cm7.out" "$PROJ_DIR$/debug/hello_world_demo_cm7.bin""

1.2 Keil MDK下

编译hello_world_demo_cm7.uvprojx工程（也选择debug build），会在工程目录debug文件夹下生成可执行文件hello_world_demo_cm7.out。如果在工程选项Output里开启Create HEXfile，则可以生成hex格式镜像文件，不过要想生成其他bin/srec格式镜像文件需要想其他办法。

MDK下其实也有类似IAR下的镜像文件转换小工具，即 \Keil_v5\ARM\ARMCC\bin\fromelf.exe，这个小工具可以帮助生成其他格式的镜像文件。

fromelf.exe --bin app.out --output app.binfromelf.exe --i32 app.out --output app.hexfromelf.exe --m32 app.out --output app.srec

在工程选项User里的After build添加如下调用formelf.exe做转换的命令就可以得到指定格式的镜像文件了。

$K\ARM\ARMCC\bin\fromelf.exe --bin --output=debug\@L.bin !L

二、MCUXpresso下生成镜像文件的方法

MCUXpresso IDE 下生成镜像文件的方法与IAR/MDK稍有不同，其并不是在工程选项里去开启，而是工程目录里会有Binaies虚拟文件夹（如果看不到该文件夹，可以按 F5 刷新一下），编译完成后在Binaies文件夹下会看到可执行文件(evkmimxrt1170_hello_world_demo_cm7.axf)，右击可执行文件在Binary Utilities里可以看到不同格式镜像文件生成选项。

我们知道MCUXpresso IDE是基于标准ARMGCC的二次封装，所以其生成镜像文件的能力其实是依靠\MCUXpressoIDE_11.6.0_8187\ide\tools\bin\arm-none-eabi-objcopy.exe 小工具。

arm-none-eabi-objcopy.exe -O binary app.axf app.bin

arm-none-eabi-objcopy.exe -O ihex   app.axf app.hex

arm-none-eabi-objcopy.exe -O srec   app.axf app.srec

因此在MCUXpresso IDE下我们也可以像IAR/MDK那样添加Post-build steps命令来完成镜像文件的生成。

arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"

关于FlexSPI外设的lookupTable，之前写过一篇非常详细的文章 《从头开始认识i.MX RT启动头FDCB里的lookupTable》，这篇文章几乎可以帮助解决所有串行QuadSPI NOR Flash（四线） 以及Octal Flash（八线）的读时序配置问题，因为这些Flash都只用单一行地址（Row Addr）来寻址。

但是市面上也有一些特殊的存储器（比如八线HyperBus Flash/RAM，OctalRAM等）采用了行列混合寻址方式，对于这类存储器，我们在FlexSPI里配置读时序，尤其是读时序里的地址序列参数值时需要稍微注意一下，今天就来聊聊这个话题：

一、FlexSPI外设关于行列地址 Memory支持

先来看FlexSPI外设是如何支持行列混合寻址存储器的。

在FLSHxxCR1寄存器里有CAS控制位，这里配置的即是存储器列地址（Column Addr）位宽。对于不支持列地址的存储器，CAS需要设置为0；如果存储器支持列地址，那么CAS需要根据存储器实际情况来设置。

如果FLSHxxCR1[CAS]位不为0，那么FlexSPI外设在传输时序里会拆分实际映射Flash Address（即存储器自身偏移地址）为行地址FA[31:CAS]和列地址[CAS-1:0]来分别传输。

在最终lookupTable里我们可以用这样的时序配置来实现存储器的读访问，这里RADDR_DDR子序列即传输行地址，CADDR_DDR子序列即传输列地址（注：如下示例是在FLSHxxCR1[CAS] = 3的设置下）。

看到这里，似乎已经把FlexSPI对于行列地址Memory的支持讲完了。

但是我相信你还是会有疑问，上面序列表里RADDR_DDR和CADDR_DDR具体参数值设置似乎没有讲清楚，为什么行列地址加起来位宽是0x18 + 0x10一共40bit（一般 Memory行列地址总位宽也就32 bit）？并且明明CAS值只是 3，为何CADDR_DDR 里设成0x10也行？

是的，这里需要再详细展开!

首先我们要明白一点，因为FlexSPI连接的是八线Memory，在实际总线上行、列地址传输位一定都是8bits的整数倍，如果RADDR/CADDR_DDR参数值设置得不是8bits的整数倍，不足8bits的部分，FlexSPI会自动在低位插入相应保留位（即下图低保留bits，这些保留位的值是什么不确定，对FlexSPI来说也不在乎），然后在 RADDR/CADDR_DDR设置的参数值范围内，如果对应Memory实际行、列地址位宽小于参数值，超出实际行、列地址的部分会被FlexSPI自动填入0值（即下图高亮填充bits）。

二、常见行列混合地址Memory 读配置实例

大部分 HyperBus Flash/RAM 在行、列地址设计上是一样的，这里罗列了市面上常见的型号如下，我们就以MIMXRT1050-EVKB板卡上那颗S26KS512为例来介绍。

1、ISSI的IS26KSxxx系列HyperFlash
2、ISSI的IS66/67WVH系列HyperRAM
3、Cypress/Infineon的S26KSxxx系列HyperFlash
4、Cypress/Infineon的S80KSxxx系列HyperRAM
5、Winbond的W957D8、W959D8系列HyperRAM

我们在S26KS512手册里可以找到如下读时序图，主要关注时序最前面48bits的Command-Address序列，在手册Command / Address Bit Assignments表里有这48bits的详细定义，其中CA[37:16] 是行地址与高位列地址，CA[2:0] 是低位列地址。

再来看 \SDK_2_12_0_EVKB-IMXRT1050\boards\evkbimxrt1050\driver_examples\flexspi\hyper_flash\polling_transfer 例程里的如下lookupTable，RADDR_DDR参数值是0x18，CADDR_DDR参数值是0x10，根据上一节的分析，RADDR_DDR里的高2bits会被FlexSPI设为0（RADDR[21:0]用于传输CA[37:16]）。

因为CAS = 3，所以CADDR_DDR里的高13bits也会被FlexSPI设为0（CADDR[2:0]用于传输CA[2:0]），这是符合S26KS512手册时序定义的。

flexspi_device_config_t deviceconfig = {
    .columnspace          = 3,
    .enableWordAddress    = true,
};

const uint32_t customLUT[CUSTOM_LUT_LENGTH] = {
    /* Read Data */
    [0] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR,       kFLEXSPI_8PAD, 0xA0, kFLEXSPI_Command_RADDR_DDR, kFLEXSPI_8PAD, 0x18),
    [1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_CADDR_DDR, kFLEXSPI_8PAD, 0x10, kFLEXSPI_Command_READ_DDR,  kFLEXSPI_8PAD, 0x04),
};

三、特殊行列混合地址Memory 读配置实例

最近我们在支持客户的过程中也发现了一些Memory有着不一样的行、列地址设计，比如如下这颗IS66WVO OctalRAM。从手册里找到其Command / Address bit assignment表里48bits的定义。与上一节HyperBus Flash/RAM不一样的是，其高位列地址并不是在8bits对齐处出现的。

1. ISSI出品的IS66/67WVO系列OctalRAM

对于IS66WVO这样的行、列地址设计，我们在lookupTable里该如何填入RADDR/CADDR_DDR参数值呢？首先CAS设为4，CADDR_DDR设为0x08可以解决CA[3:0]传输问题。

现在的重点是RADDR_DDR参数值，总共24bits传输位，低位还需要留2个保留位，所以RADDR_DDR仅能被设为0x16（RADDR[20:2]用于传输RA[12:0] + CA[9:4]），即如下面代码：

flexspi_device_config_t deviceconfig = {
    .columnspace          = 4,
    .enableWordAddress    = false,
};

const uint32_t customLUT[CUSTOM_LUT_LENGTH] = {
    /* Read Data with continuous burst Sequence in DDR command mode */
    [0] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DDR,       kFLEXSPI_8PAD, 0xA0, kFLEXSPI_Command_DDR,       kFLEXSPI_8PAD, 0x00),
    [1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_RADDR_DDR, kFLEXSPI_8PAD, 0x16, kFLEXSPI_Command_CADDR_DDR, kFLEXSPI_8PAD, 0x08),
    [2] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DUMMY_DDR, kFLEXSPI_8PAD, 0x1E, kFLEXSPI_Command_READ_DDR,  kFLEXSPI_8PAD, 0x04),
};

作者：Stella Or

开发边缘连接技术的原始设备制造商（OEM）需要考虑其软件知识产权以及作为安全产品提供商的声誉。经济高效的生产往往会与保护云端所用的知识产权和器件认证直接冲突。恩智浦认为永远不能牺牲安全性，并提供了具有新的智能卡可信配置（Smart Card Trust Provisioning）功能的解决方案。

恩智浦i.MX RT1180跨界MCU可以实现多协议工业物联网通信，同时为实时以太网和工业4.0系统提供支持

恩智浦半导体（NXP Semiconductors N.V.，纳斯达克股票代码：NXPI）宣布推出新型i.MX RT1180跨界MCU，作为系列首款集成千兆（Gbps）时间敏感网络（TSN）交换机的微控制器，能够同时实现时间敏感型和工业实时通信，并支持多种通信协议，弥合了现有工业系统和工业4.0系统之间的沟通间隙。这款跨界MCU还带有EdgeLock®安全锁区，它是一种预先配置的自管理式自主片上安全子系统，为工业物联网应用实现可靠的系统级安全智能降低复杂性。

产品重要性

工业环境逐渐向工业4.0发展，网络协议的组合变得越发复杂，时间敏感型通信和实时通信之间难以实现无缝的工业连接。i.MX RT1180提供了实现无缝连接所需的多协议连接能力，可在工厂所有边缘设备间推动实现统一、安全的工业物联网通信环境。集成的EdgeLock安全锁区可以为复杂的网络系统提供安全启动、验证调试、生命周期安全管理、高级密钥管理和篡改监控功能，从而满足对信任根的需求。

更多详情

i.MX RT1180提供多种封装选项，最小封装为10x10mm BGA，以超小尺寸满足实时工业网络所需功能，更轻松地将TSN和工业网络相关功能集成到更广泛的工业应用中，包括I/O管理、电机控制、紧凑型运动控制或网关应用。除了单独作为集成解决方案外，i.MX RT1180还可用作网络系统中的辅助芯片，通过可扩展连接能力为主机处理器提供所需的所有工业网络连接，无需板载PHY即可实现与主机的无缝千兆直接通信，从而可节省额外的功耗和成本。此外，汽车连接应用越来越依赖以太网TSN的支持以实现高带宽和传输实时控制数据，i.MX RT1180同样能够在这方面一展身手。在汽车领域，i.MX RT1180可用作不同的汽车ECU之间的智能开关。

恩智浦资半导体工业边缘处理事业部副总裁兼总经理Jeff Steinheider表示： “工业和汽车行业的客户希望能够提供越来越先进的网络功能，因此要求解决方案不仅具备处理能力，还能管理时间敏感型网络流量。i.MX RT1180提供了集成交换机和EdgeLock安全锁区的一体化解决方案，能够同时满足汽车和工业物联网应用的需求，处理时间敏感型流量和非时间关键型流量，从而帮助客户实现具有先进实时通信功能的安全自动化系统。”

i.MX RT1180作为一款高性能跨界MCU，可在-40°C至125°C的扩展工业级温度范围内工作，采用双核架构，集成800 MHz Arm®Cortex®-M7和Cortex-M33内核，可实现设计灵活性。该器件的集成PMIC（电源管理集成电路），专为实现高能效而设计，适合设计功耗为250mW及以上的应用场景，有助于让许多工业应用实现出色的能效，同时还可降低电路板的复杂性和成本。i.MX RT1180配备多达5个千兆网口，并支持最新的TSN标准，以及多种工业实时网络协议，包括EtherCAT、Profinet、Ethernet/IP、CC-Link IE或HSR等。i.MX RT1180还可帮助OEM厂商轻松地使设备达到ISA/IEC 62443-4-1、-4-2标准。