i.MX RT1010

2023年10月12日，致力于亚太地区市场的国际领先半导体元器件分销商---大联大控股宣布，其旗下世平推出基于恩智浦（NXP）i.MX RT1010芯片的扫地机器人方案。

图示1-大联大世平基于NXP产品的扫地机器人方案的实体图

在生活节奏日益加快的当下，消费者愈发希望从繁琐的家庭清洁事务中解脱出来，于是扫地机器人应运而生。作为一种家庭劳动机器人，能够准确感知周围坏境、并自主进行路径规划和导航是实现高效清洁的前提。为了能够提高机器人的感知能力，大联大世平基于NXP i.MX RT1010推出扫地机器人方案，该方案集成了高清摄像头模组和传感器板，能够准确识别周围环境，满足扫地机器人的应用需求。

图示2-大联大世平基于NXP产品的扫地机器人方案的场景应用图

本方案分为Camera Board和Sensor Board两个部分。其中，Camera Board作为主控板，以i.MX RT1010 MCU为核心。i.MX RT1010 MCU基于Arm^® Cortex^®-M7内核，具有128KB SRAM和高达500MHz主频，并且集成丰富的外设资源，可以为开发者提供更大的设计空间。Camera Board可连接OV7670摄像头模块和LCD模块作为摄像头模组，来实现视频图像捕捉的应用需求。Sensor Board则集成包括气压、环境光、光谱、ToF等各种传感器，能够有效提高机器人的环境感知能力。

图示3-大联大世平基于NXP产品的扫地机器人方案的方块图

随着智能家居不断渗透，扫地机器人的市场规模还将持续增长。在这种趋势下，大联大世平将继续联合原厂合作伙伴推出更多解决方案，提升扫地机器人的智能体验。

核心技术优势：

高性能低成本RT1010跨界MCU可应对扫地机摄像头视频图像捕捉的应用需求，FlexIO模拟CSI最高支持120fps视频图像传输，具备性能和成本优势。

方案集成扫地机应用需要的各种传感器，可以通过I²C接口，获取气压、环境光、光谱、ToF数据。

方案集成LED Driver，可通过I²C驱动板载绿激光、紫外线，通过RGB接口可扩展控制6组RGB灯。

方案规格：

Camera Board：

搭配OV7670摄像头和2.4英寸240×320 RGB TFT LCD显示屏，最高支持30fps的帧率捕捉图像数据，并将图像数据显示到LCD屏上。

Sensor Board：

支持AW21024 LED Driver驱动PLT5 510绿激光光电二极管发射出绿激光；

支持AW21024 LED Driver控制6组RGB灯，产生各种灯光效果；

支持NSPGS2F035DT09气压传感器，测量当前环境的气压数据；

支持ToF TMF8801测距传感器，测量传感器距离前方物体的距离；

支持TMD2755接近和环境光传感器，测量前方物体距离传感器的接近程度，以及环境的光强和红外光强度；

支持TCS3440光谱传感器，具有8个可见光通道，能够计算得到环境光的色温和光强。

如有任何疑问，请登陆【大大通】进行提问，超过七百位技术专家在线实时为您解答。欢迎关注大联大官方微博（@大联大）及大联大微信平台：（公众账号中搜索“大联大”或微信号wpg_holdings加关注）。

关于大联大控股：

大联大控股是全球领先、亚太区最大的半导体元器件分销商*，总部位于台北(TSE:3702)，旗下拥有世平、品佳、诠鼎及友尚，员工人数约5,000人，代理产品供货商超250家，全球78个分销据点，2022年营业额达259.7亿美金。大联大开创产业控股平台，专注于国际化营运规模与在地化弹性，长期深耕亚太市场，以「产业首选．通路标杆」为愿景，全面推行「团队、诚信、专业、效能」之核心价值观，连续22年蝉联「优秀国际品牌分销商奖」肯定。面临新制造趋势，大联大致力转型成数据驱动(Data-Driven)企业，建置在线数字化平台─「大大网」，并倡导智能物流服务(LaaS, Logistics as a Service)模式，协助客户共同面对智能制造的挑战。大联大从善念出发、以科技建立信任，期望与产业「拉邦结派」共建大竞合之生态系，并以「专注客户、科技赋能、协同生态、共创时代」十六字心法，积极推动数字化转型。(*市场排名依Gartner 2023年03月公布数据)

围观 12

工业产品设计里经常会有冗余程序/备份程序设计的需求，因为在工业环境里要求设备能够持续稳定运行，不能轻易宕机，但现实环境中常常有各种意外发生，其中一个常见的意外就是设备主控MCU程序被破坏。

为了降低程序损坏这种意外带来的影响，一个很典型的做法就是增加MCU程序的份数，第一份被破坏，就启动第二份...，用程序数量的增加来降低启动失败率，这属于概率学手段范畴。

我们知道恩智浦i.MX RT系列MCU内部没有非易失性存储器，它需要搭配外部存储器来工作，可选存储器类型非常多：NOR Flash, NAND Flash, eMMC, SD卡都行。

其中对于NAND型存储器，冗余程序设计是必备的，因为NAND本身允许坏块现象存在，所以不得不做冗余设计。而对于NOR型存储器，冗余设计则不是必需的，偏偏串行NOR Flash是i.MX RT最常用的搭档，那该怎么办？别急，今天痞子衡介绍的就是i.MX RT1010/1060上串行NOR Flash冗余程序设计，恩智浦已经都给你考虑到了。

注：本文所涉及的串行NOR Flash冗余程序设计，不支持早期的i.MX RT1050/1020/1015型号。

一、初识冗余程序启动

在i.MX RT上可以挂载串行NOR Flash去启动程序的外设有两个，分别是FlexSPI和 LPSPI，如下图所示。

注：并不是所有 i.MXRT 型号都支持 LPSPI 外设挂载存储器去启动。

其中连接在FlexSPI 上的 Flash A 属于主启动设备，连接在LPSPI上的Flash B属于备份启动设备（关于备份设备启动详见痞子衡旧文《从Serial(1-bit SPI) EEPROM/NOR恢复启动》）。

用两片NOR Flash去完成冗余程序设计当然是没问题，但也相应增加了硬件成本，而本文今天要讨论得不是这种冗余程序设计，我们要聊的是在一片挂载在FlexSPI上的串行 NOR Flash里做冗余程序设计，就是图中的image 0和image 1。

冗余程序启动流程其实特别简单，上电永远先启动物理地址靠前的image 0，如果 image 0被破坏了，则启动image 1。原则上image 0和image 1应该是完全一样的（链接地址也一样，并且中途不需要搬移这两份image数据，这个是靠芯片里的一个黑科技做到的，下文会细讲），毕竟是冗余设计，不过你要执意放两份不完全一样的image，倒也没问题。

二、实测冗余程序启动

我们知道i.MX RT芯片上电总是先运行厂商固化好的BootROM，所以冗余程序启动设计是做在BootROM代码里的。之前有一篇旧文《了解i.MXRT1060系列ROM中串行NOR Flash启动初始化流程优化点》中2.1 节其实已经简单地提到了冗余程序设计，其主要借助了芯片系统FlexSPI地址重映射(Remap)功能，这个功能是在恩智浦后期推出的 i.MX RT1060/1010 等型号上才有的，这也是上文所说的黑科技。关于这个黑科技，痞子衡也有旧文《利用i.MXRT1060,1010上新增的FlexSPI地址重映射(Remap)功能可安全OTA》。

有了FlexSPI Remap黑科技存在，我们就可以将同一份image binary放在Flash中两个不同位置，并且不用做擦除编程操作来交换其位置，就可以实现各自的启动执行。如果没有这个黑科技，我们只能老老实实做数据搬移，这会增加擦除次数从而影响Flash使用寿命。

原理搞清楚了，现在我们在板子上实测一下这个功能，看看如何正确地放两份image进Flash，哪些情况会导致image 0启动失败从而去启动image 1。

我们就以恩智浦官方MIMXRT1060-EVK开发板为例，这个板子FlexSPI1上挂了两片 Flash，默认连接的8MB QuadSPI Flash，还有一片64MB HyperFlash（需要做板子改动才能使能）：

2.1 使能冗余程序启动

使能冗余程序启动特性很简单，就是将fuse 0x6E0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET烧录为非0值即可，根据下面定义，第二份image 偏移地址最大可以设到Flash中0x3FC0000（63.75MB）处：

Remap功能的ADDR_START寄存器固定设为Flash 起始映射地址。

fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，App的最大长度，标识了第一份App的结束地址，该值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。

fuse 0x6e0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET，标识了第二份App的起始地址（在Flash中偏移位置），即填入Remap功能的ADDR_OFFSET寄存器的值。

本次测试，我们就将FLEXSPI_NOR_SEC_IMAGE_OFFSET烧录为0x10，xSPI_FLASH_IMAGE_SIZE保持默认0，即第二份image 偏移地址在Flash 0x400000（4MB）处，最大image长度也是4MB，可借助MCUBootUtility工具完成Fuse烧录：

2.2 下载两份无签名image进Flash

现在开始准备image，我们就直接用\SDK_2.10.1_EVK-MIMXRT1060\boards\evkmimxrt1060\demo_apps\led_blinky例程，简单直观。为了便于肉眼分辨效果，我们生成两个稍微不一样的image，闪灯间隔时间一个是200ms（image 0 - iled_blinky_delay200ms.bin），另一个是2s（image 1 - iled_blinky_delay2s.bin）：

然后还是借助MCUBootUtility工具，先使用All-In-One操作将image 0下载进Flash，因为是bin文件，所以我们要填入正确的链接起始地址（对于i.MX RT1060就是 0x60000000；对于i.MX RT1010应该是0x60000400，具体查看工程链接文件便知）。

此外我们使用的是完整的可启动镜像文件（包含了全部所需启动头），也可以直接在软件通用编程器界面做下载。

image0下载进Flash后，继续下载image 1，这时候只能在软件通用编程器界面操作。这里主要是设置好下载起始地址，前面我们使能冗余程序启动时在Fuse里设置的偏移地址是0x400000，那么此时下载起始地址就应该是0x400000（对于i.MX RT1060是0x400000；对于i.MX RT1010应该是0x400400）。至此两份image下载就完成了。

2.3 快速验证两份image正确性

现在Flash里有了两份image，我们来做一个快速验证，看看image是不是放得符合冗余程序启动的要求。对于image 0，没什么好说的，芯片启动模式设为2'b10 后断电复位应该可以看到image 0在执行，最重要的是验证image 1是不是合法。

这里开始涉及到芯片冗余程序启动流程核心了，当image 0启动失败后，芯片BootROM不是立刻去执行image 1的，它用了一个取巧的方式，在一个软复位不置位的寄存器里（SRC_GPR10）标记了当前状态，然后调用NVIC_SystemReset()重新进入BootROM执行，第二次BootROM执行时才会去启动image 1。

所以这也给了我们快速验证image 1执行的可能性，我们在板子上挂上J-Link仿真器，然后打开J-Link Commander，直接将SRC_GPR10寄存器改写为0x40000000，再依次执行reset和go命令，这时你应该可以看到image 1正在执行了。

2.4 测试无签名 image 0 损坏条件

痞子衡之前在《i.MXRT Bootable image格式》一文里介绍过一个可启动image包含哪些组成部分，其中最简单的无签名image应该至少包含FDCB, IVT, BD, App四部分，芯片BootROM也是按序读取这四部分数据完成程序启动的。

现在我们尝试分别破坏这几个组成部分来看看何种程度的image 0损坏能被BootROM识别出从而去启动image 1，下面是测试结果。从测试结果来看，除了Image 0 - App的损坏无法检测外，image 0其余启动头的损坏都可以被BootROM识别到。

2.5 能检测image 0 app损坏的方法

如果不能检测image app部分的损坏，那这个冗余程序启动功能就比较鸡肋了，毕竟app部分的数据才是整个image核心所在。如果要加上app损坏检测，需要使能i.MX RT 签名启动，还是可以借助MCUBootUtility工具完成全部流程，下载两份含签名的image进Flash的过程跟2.2节基本差不多，只是Secure Boot Type里需要选择 "HAB Signed Image Boot"，含签名的image 0下载没什么好说的，All-In-One操作全搞定，含签名的image 1数据可以通过在通用编程器界面里将含签名的image 0数据全部读回得到，这个具体操作就不详细展开了。

含签名image 0相比无签名image 0多了HABdata(csf,cert,signature) 数据段，BootROM在跳转image之前会根据HAB data数据对image进行验签，验签通过才做跳转。

此时再做一次破坏实验，结果如下，显然加了签名的image 0其完整性就有保证了，这时的冗余程序启动设计才能发挥出最大效果。

来源：恩智浦MCU加油站（作者：痞子衡）
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。

围观 61

最近客户在使用i.MX RT1010的I2C作为从机设备与主机通讯，使用了时钟延展的功能（clock stretching）。在开发过程中遇到了一些小烦恼和小细节，在此呢，也写下一篇文档予以总结。

什么是时钟延展

首先，简单介绍一下什么是时钟延展。时钟延展是指从机通过将SCL拉低以暂停数据传输的一个过程，在暂停过程中，从机可以有更多的时间处理接收到的数据，或者准备即将发送的数据。在相关的处理和准备完成之后，将交出SCL的控制权，主机继续控制SCL的节奏进行数据的收发。换句话说，时钟延展是从机跟不上主机的速度，让老司机等等它，啊不，是让主机等等它的操作。

时钟延展通常分为两种，一种是字节级(byte)的时钟延展，一种是比特级（bit）的时钟延展。字节级的时钟延展是按照字节为单位开展，每一个字节收发结束之后启动。比特级则是每个数据bit都进行延展，强行让master慢下来。

在查阅相关资料的过程中发现，并不是所有的I2C从机设备都支持时钟延展，例如I2C的传感器，部分存储设备；也并不是所有的主机设备也支持时钟延展，例如使用IO口模拟实现的I2C或者是FPGA上实现的I2C。因此在使用之前，需要检查器件自身是否支持时钟延展。

四种时钟延展功能

在我们i.MX RT1010上总共支持4种字节级的时钟延展：

下面我们将对这四种时钟延展的功能进行简要介绍，以下介绍均为从机视角。

延展功能1：收完地址等一等

在从机接收完主机发送的地址信息后，且AVF 置位，则此时从机获得SCL的控制权，开始持续拉低SCL开启时钟延展。那么什么时候结束呢，从硬件状态机的角度看，当AVF bit被清除，时钟延展结束，主机获得SCL的控制权。

举个例子，用我们SDK工程在接收到地址信息后强行延时500us再去清除AVF bit, 看看波形是怎样的：

从图中可以看到，两次时钟间隔约491us,基本上与500us的预期相匹配。并不是完美的500us的原因是，延时函数没有使用定时器精确延时。

延展功能2：发送之前等一等

在从机接收到主机的地址信息和读指令后，TDF将会置位，则此时从机获得SCL的控制权。同样是在清除TDF bit之后，主机再次获得SCL的控制权。在这个过程中，从机可以根据主机发送的信息，把要发送的数据准备好，再释放SCL的控制权。同样举个例子，再清除TDF bit 之前等一等，这次等的长一点800us。

延展功能3：接收之前等一等

在从机接收到数据之后，RDF会置位，此时从机会获得SCL的控制权。同样是在清除TDF bit之后，主机再次获得SCL的控制权。拉个波形看看，在清标志位前拉个1000us的延时，波形如下图所示。

延展功能4：手动回ACK

这里是指，当主机把数据（地址信息或者数据信息）发送给从机后，在传送完第八个bit（或者说是第八个时钟）之后，从机即获得了SCL的控制权限，在此时需要手动向STAR寄存器中最后一位写0或者1，以向主机反馈ACK 或者NACK。在写0之前，我们增加一个500us的延时，地址信息的波形见下图，可以看到第八个和第九个CLK时钟的间隔被拉长。