NOR Flash

“应需而生!兆易创新推出突破性1.2V超低功耗SPI

兆易创新今日宣布,推出突破性的1.2V超低功耗SPI NOR Flash产品——GD25UF系列。该系列在数据传输速度、供电电压、读写功耗等关键性能指标上均达到国际领先水平,在针对智能可穿戴设备、健康监测、物联网设备或其它单电池供电的应用中,能显著降低运行功耗,有效延长设备的续航时间。

“”

随着物联网技术的发展,新一代智能可穿戴设备需要拥有更丰富的功能来满足消费者的需求,这种空间敏感型产品对系统功耗提出了更严苛的要求,希望进一步提升产品的续航能力。

从系统设计层面来看,一些先进工艺器件的工作电压已低至1.2V,如果所需的Flash可支持1.2V的电压操作,这对于主控而言,将能够有效简化电源设计并优化系统成本。

应此需求,兆易创新推出了GD25UF产品系列,该系列工作电压可扩展至1.14~1.6V,具有单通道、双通道、四通道、和DTR四通道的SPI模式,支持不同容量选择,能够满足智能设备所需的代码存储要求。

在读写性能方面

GD25UF最高时钟频率STR 120MHz,DTR 60MHz,拥有10万次的擦写寿命,数据有效保存期限可达20年。

在安全性方面

该产品具有128bit Unique ID来实现加密效果,为应用带来高安全保障。

同时,为进一步满足低功耗的需求,GD25UF产品系列特别提供了Normal Mode和Low Power Mode两种工作模式。在Normal Mode下,器件读取电流在四通道120MHz的频率下低至6mA;在Low Power Mode下,器件读取电流在四通道1MHz频率下低至0.5mA,擦写电流低至7mA,睡眠功耗低至0.1uA。

相比于1.8V供电的SPI NOR Flash,1.2V GD25UF系列在Normal Mode下,相同电流情况下的功耗降低了33%,而在Low Power Mode下,相同频率下的功耗降低了70%,有效延长了设备的续航时间。

另外GD25UF系列产品的供电电压支持1.14~1.6V的宽电压范围,可显著延长单电池供电应用的使用寿命。并且该系列产品支持SOP8、WSON8、USON8、WLCSP封装,全温度工作范围覆盖-40℃~85℃、-40℃~105℃、-40℃~125℃。

兆易创新存储器事业部执行总监陈晖先生表示:

“GD25UF系列产品进一步丰富了兆易创新的Flash Memory产品线。其具备的1.2V低电压和超低功耗模式可以帮助小容量电池供电设备提高续航能力,即使在不可避免的电池衰减过程中,也可以保持出色且稳定的运行状态,增加应用的可靠性。如今,电池续航能力已经成为消费者选购产品的重要指标,GD25UF系列产品的问世会是下一代可穿戴设备的理想选择。作为国内外鲜少拥有1.2V SPI NOR Flash产品线的企业,兆易创新走在了需求前端,为下一代应用的设计开发缓解了压力,从一定程度上缩短了客户的研发成本,让他们能够在日益激烈的市场竞争中保持领先地位。”

目前,兆易创新GD25UF系列可提供64Mb容量样品,更多容量产品将陆续推出,客户可联络销售代表或授权代理商了解相关的信息。

来源:兆易创新GigaDevice
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 9

兆易创新今天宣布,推出GD25WDxxK6 SPI NOR Flash产品系列,采用1.2mm×1.2mm USON6超小型塑封封装,最大厚度仅为0.4mm,在如此紧凑、轻薄的空间内,其功耗、电压范围等方面均实现了进一步提升,为消费电子、可穿戴设备、物联网以及便携式健康监测设备等对电池寿命和紧凑型设计有着严苛需求的应用提供了理想选择。

“兆易创新GD25WDxxK6

如今,随着5G、物联网、AI等技术的不断迭代,在笔记本摄像头、智能遥控器、智能健康手环等采用电池供电的应用场景中,兆易创新对“小而精”的追求从未停止,这对应用其中的存储产品提出了更高的要求。

一方面,需要提供足够的代码存储空间来满足设备正常运行需求;

另一方面,也需要在尺寸和功耗方面追求精益求精,以适应电子设备日益小型化的趋势。

针对这一市场需求,兆易创新推出的GD25WDxxK6 SPI NOR Flash产品系列采用仅为1.2mm×1.2mm的超小型USON6封装,相比于前一代1.5mm×1.5mm USON8封装产品,缩小了高达36%的占板面积,为空间受限的产品提供了更大的设计自由度。

在低功耗设计方面,兆易创新将GD25WDxxK6系列的功耗控制在极低水平内,在待机状态下,电流仅为0.1μA,可显著延长电子设备的电池寿命。

此外,为满足便携式电子产品的存储需求,GD25WDxxK6提供单通道、双通道SPI模式,具有1.65V~3.6V宽电压工作范围,支持512Kb~4Mb不同容量的选择,最高时钟频率可达104MHz,拥有10万次的擦写寿命,数据有效保存期限可达20年,且全系列支持-40℃~85℃, -40℃~105℃, -40℃~125℃温度范围。

兆易创新存储事业部执行总监陈晖先生表示:“随着万物互联时代下的数据狂潮席卷而来,电子设备对于存储产品不断发出挑战,而兆易创新要做的就是从挑战中寻求突破。此次推出的1.2mm×1.2mm的超小型USON6 GD25WDxxK6 SPI NOR Flash,在方寸之间实现了优异性能。从小尺寸到低功耗,兆易创新从用户需求出发,不断推陈出新,再次将我们‘创新’的DNA发挥得淋漓极致。”

目前兆易创新GD25WDxxK6系列中512Kb~1Mb容量产品已全面量产;2Mb~4Mb容量产品可提供样片,预计在8月中旬实现量产,客户可联络销售代表或授权代理商了解相关的信息。

来源:兆易创新GigaDevice
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 12

在上一篇文章“i.MX RT1170上串行NOR Flash双程序可交替启动设计”里,详细介绍了i.MX RT11xx 系列上的双程序启动设计,本质上就是在双备份程序启动基础上增加了 image版本控制,所以两份image可以按版本优先级来灵活选择启动,而不是死板地靠物理地址高低来定启动顺序。

i.MX RTxxx 系列上(RT500/600)也有双程序可交替启动特性,其主体设计逻辑基本上跟i.MX RT1170是差不多的,只是一些细节处略有差异(比如可启动image 结构不同、otp 配置地址不同、签名实现不同、非易失性寄存器暂存状态设计不同、image 版本判断逻辑略有不同等),除此之外i.MX RTxxx上在验证image完整性方面除了签名外,还有一种相对平民化的CRC32校验可供选择,这也是今天本文要介绍的重点:

一、与i.MX RT11xx系列双程序启动细节差异

本文不打算从头开始完整介绍 i.MX RTxxx 上双程序可交替启动特性,这里只讲和 i.MX RT11xx 上的差异点,其余流程直接参考“i.MX RT1170上串行NOR Flash双程序可交替启动设计”一文。

1.1 恢复启动的接口外设不同

第一点不同其实与本文要讨论的 FlexSPI 双程序启动特性无关,因为我们要聊的还是在一片挂载在 FlexSPI 上的串行 NOR Flash 里做双程序设计,就是下图中的 image 0 和 image 1,不涉及 Flexcomm SPI 接口 Flash B 里的 image 2(在 i.MX RT1170 上这个外设是 LPSPI)。

在介绍 i.MX RT1170 双程序启动一文里我们用了 image L/H 来表示 image 0/1,这里还是恢复使用 image 0/1 来表示,因为后面我们要看的i.MX RT500/600 参考手册启动流程图里就是用 image 0/1来表达的,避免表达混乱。

“i.MX

1.2 可启动 image 结构不同

i.MX RT1170上最简易可启动image结构比较复杂(包含 FDCB、img_ver、IVT、BD、App),而 i.MX RTxxx上就比较简单了(仅需 FDCB、img_ver、App),但是好在两者关于 image version 头结构定义以及偏移位置是完全一致的(0x600)。

typedef struct
{
    uint16_t version;     // 版本值
    uint16_t inversion;   // version值的取反(~version)
} img_ver_t;

此外i.MX RT1170上第一个FlexSPI 的 AHB 映射地址是 0x3000_0000,而 i.MX RTxxx 上第一个 FlexSPI 的 AHB 映射地址是0x0800_0000,这是系统设计差异,需要注意。

注:下图中示意地址均是 Flash 偏移地址,没有包含 AHB 映射地址,另外这里假设第二份 image 偏移地址在 0x400000(具体是由 otp 配置值来决定的)。

“i.MX

1.3 使能双程序启动的otp配置地址不同

i.MX RTxxx 上关于使能双程序启动的 otp 配置定义与i.MX RT1170 上是一致的,只是因为两者 otp 空间设计不同,所以具体配置地址不同。i.MX RTxxx 上具体配置在 otp BOOT_CFG2/3 上面:

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

otp 0x188[31:28] - FlexSPI remap size, App的最大长度,标识了第一份App的结束地址,该值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。

otp 0x18C[31:22] - Second image offset,标识了第二份App的起始地址(在Flash中偏移位置),即填入Remap功能的ADDR_OFFSET寄存器的值。

“i.MX

这次我们要在 MIMXRT595-EVK 板卡上实测,这个板子 FlexSPI0 上挂了两片 Flash,默认连接64MB OctalFlash,还有一片 8MB QuadSPI Flash(需要做板子改动才能使能)。为了跟之前测试保持一致,还是借助 MCUBootUtility 工具将 Second image offset 烧录为 0x10,FlexSPI remap size 保持默认 0,即第二份 image 偏移地址在Flash 0x400000(4MB)处,最大 image 长度也是 4MB。

“i.MX

1.4 暂存状态的非易失寄存器有差异

i.MX RT1170 是用非易失寄存器 SRC_GPR10 其中 2bit 来记录当前启动状态的,而 i.MX RTxxx 上则复杂得多,它采用了 SYSCTL0 外设里的一个非易失寄存器的全部 32bit 来暂存启动状态。

// Load redundant boot options stored in specific register
#define LOAD_REDUNDANT_BOOT_OPTIONS() (*(volatile uint32_t *)(SYSCTL0_BASE + 0x384))

// Store redundant boot options in specific register before system reset
#define SET_REDUNDANT_BOOT_OPTIONS(val) ((*(volatile uint32_t *)(SYSCTL0_BASE + 0x384)) = val

这个32bit寄存器功能原型如下,它不单纯是用做双程序启动的状态记录了,还糅合了 ROM API 功能。具体用法可以在芯片参考手册 ROM API 小节找到,这里不具体展开了,不是本文重点。

typedef struct _user_app_boot_invoke_option
{
    union
    {
        struct
        {
            uint32_t reserved : 8;
            uint32_t boot_image_index : 4;
            uint32_t instance : 4;
            uint32_t boot_interface : 4;
            uint32_t mode : 4;
            uint32_t tag : 8;
        } B;
        uint32_t U;
    } option;
} user_app_boot_invoke_option_t;

1.5 image 版本判断逻辑不同

在 i.MX RT1170 上 image version 头有效的条件一定是其高低16bit符合取反关系,而 i.MX RTxxx 上除了这个条件外,其认定 0xFFFFFFFF 也是一个有效版本(被定为最低版本)。

芯片参考手册里有比较详细的 version 判断逻辑如下,这个逻辑跟 i.MX RT1170 上差异还是比较大的,i.MX RTxxx 上 BootROM 只会启动包含有效版本号的 image,版本有效性是 image 能被启动的一个必要条件,不像 i.MX RT1170 上版本信息只是单纯用来判断启动顺序,不作为 image 是否有效的标准。

“i.MX

在MIMXRT595-EVK开发板上对 image 版本设置情况也做了比较全面的实测,测试结果如下:

“i.MX

二、测试CRC32校验双程序启动

现在来到本文的重头戏了,如何使能 image 的 CRC32 检验启动?这个设计其实最早可追溯到 Kinetis 系列,我有一篇旧文 "Kinetis BOOT特性(完整性检测)",文章很详细地介绍了 Kinetis 系列 BootROM 里是如何支持 CRC32 校验的。

2.1 启动头CRC32参数存储位置

i.MX RTxxx BootROM 关于 CRC32 校验的设计与 Kinetis 非常类似,最大的区别就在于存储 CRC32 三大参数(起始地址,校验长度,校验值)的位置。i.MX RTxxx 上也是放在了 App 默认中断向量表里的保留空间里(offset 0x20, 0x28, 0x34),共 12 个字节。

offset 0x34 - imageLoadAddress: App加载后中断向量表首地址,也决定CRC校验起始地址

- 对于XIP image,一般固定为0x08001000(App无需加载)

- 对于Non-XIP image,App加载前存储起始地址是0x08001000,加载后到指定链接的RAM 地址,CRC计算和校验是发生在App加载后。

offset 0x20 - imageLength: 决定CRC校验总长度,一般是App 的长度(从中断向量表首地址开始到代码体结束)

offset 0x28 - crcChecksum: CRC校验值,[imageLoadAddress : imageLoadAddress + imageLength] 范围内数据的正确CRC32 结果

“i.MX

2.2 使能CRC32校验的条件

当App 默认中断向量表里 offset 0x24 处的imageType[7:0] 类型为 0x02 或者 0x05,且 offset 0x20 处的 imageLength 不为 0 时,CRC32 校验的功能就会被使能。BootROM 在做 CRC32 计算时主要有如下两个注意事项:

Note1: 指定的CRC计算范围如果包含crcChecksum这4bytes的话,在计算CRC时会自动跳过这4bytes。

Note2: 指定的CRC计算长度如果不是4字节对齐,CRC数据计算到最后会自动补0对齐。

2.3 具体CRC32算法选项

关于CRC32 算法的具体实现有很多分支,BootROM 中使用的比较主流的 MPEG2 分支,其在计算 image 具体 CRC 时主要借助了芯片内部的 CRC 模块(这个模块也常见于恩智浦 LPC 系列芯片上),这个 CRC 模块支持三种固定的 CRC 算法多项式(多项式系数不是可自由配置的),BootROM 用得就是最后一个模式选项 CRC-32:

“i.MX

BootROM中对 CRC 模块的配置代码如下:

#include "fsl_crc.h"
void crc32_init(void)
{
    crc_config_t crcUserConfigPtr;
    CRC_GetDefaultConfig(&crcUserConfigPtr);
    crcUserConfigPtr.seed = 0xffffffffU;
    crcUserConfigPtr.polynomial = kCRC_Polynomial_CRC_32;
    crcUserConfigPtr.reverseIn = false;
    crcUserConfigPtr.reverseOut = false;
    crcUserConfigPtr.complementIn = false;
    crcUserConfigPtr.complementOut = false;
}

2.4 利用工具自动添加CRC校验参数

对CRC32 校验启动的原理了解差不多了,我们现在在 MIMXRT595-EVK 开发板上实测一下,跟前面测试一样,先使用\SDK_2.10.1_EVK-MIMXRT595\boards\evkmimxrt595\driver_examples\gpio\led_output\iar\flash_debug例程生成两个闪灯间隔时间不同的程序镜像文件:image 0 -gpio_led_output_delay200ms.bin 和 image 1 -gpio_led_output_delay2s.bin。

然后借助MCUBootUtility 工具(需要 v3.5.0 版本及以上),在 Secure Boot Type 里选择 Plain CRC ImageBoot,点击 All-In-One 下载按钮(两个文件分别做两次同样的下载流程),工具会自动在 image 相应地方填充进所需的 CRC32 参数并下载进 Flash。

“i.MX

这时候在工具通用编程器模式(Boot Device Memory)里我们再读回 image 保存就可以得到两个含 CRC32 校验的程序镜像文件 image 0 -gpio_led_output_delay200ms_crc.bin 和 image 1 -gpio_led_output_delay2s_crc.bin。

以image 0 为例,根据 0x08001020 处的imageLength 信息显示,image 0 App 本身长度为 0x36e8 字节,而 App 起始偏移是 0x1000,所以我们直接是从偏移 0 地址处开始读回 0x46e8 字节作为gpio_led_output_delay200ms_crc.bin 文件数据。此外 image 0 的 CRC32 校验值已经填好了,是 0x4d8957d8。

“i.MX

2.5 手动验证CRC32校验值的方法

在使用image 0 - gpio_led_output_delay200ms_crc.bin 和 image 1- gpio_led_output_delay2s_crc.bin 做双程序启动前,我们可以先手动地验证下其中的 CRC32 校验值是否正确,痞子衡找到一个在线计算 CRC 的网站:

CRC在线校验网站:http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

在这个网站里把模式选好,然后从 gpio_led_output_delay200ms_crc.bin 文件里仅拷贝出App 部分的数据放到网站 CRC Input Data 框(注意要手动删除 crcChecksum 四个字节,另外还要检查总数据字节长度是否按 4 对齐,如果不对齐,要在数据末尾按格式补上相应的 00),最后点击网站上的 Calculate CRC!按钮可以得到结果,这里我们看到两个结果是一致的:

“i.MX

2.6 含CRC32校验的双程序启动测试

现在可以利用 image 0 - gpio_led_output_delay200ms_crc.bin 和 image 1 - gpio_led_output_delay2s_crc.bin 测试双程序启动了,继续借助 MCUBootUtility 工具的通用编程器模式将其分别下载进 0x0 和 0x400000 地址处,必要时还可以手动调整两个 image 里的版本号,测试过程中也可以稍微修改一下 image 数据再下载或者下载后再擦除一些 image 区域(故意让CRC32校验失败),最终测试结果如下:

“i.MX

三、一些关于image的注意事项

  • Note1:虽然文中所有的测试均是针对 XIP image,但这个双程序可交替启动特性对于 Non-XIP image 也同样适用。

  • Note2:如果是 XIP image,其链接地址要求固定在 Flash 偏移 0x1000 处(如果 Flash 挂在第一个 FlexSPI 上,其 AHB 地址就是 0x08001000)。

  • Note3:如果是 Non-XIP image,在 SDK 包里无法直接生成含启动头的 Non-XIP image binary,这时候可以先使用 MCUBootUtility 主界面的 All-In-One 操作下载一次 image,再通过通用编程器界面 Read 操作读回来便是含启动头的 Non-XIP image binary。

  • Note4:使能 CRC32 校验的双程序可交替启动,也是同时支持 XIP image 和 Non-XIP image 的。

相关阅读
《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》
《i.MX RT1170上串行NOR Flash双程序可交替启动设计》

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

围观 18

在前一篇文章 《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》里,我详细介绍了i.MX RT10xx上的冗余程序启动设计,本质上这就是个双备份程序启动, NORFlash里存两份一样的image,物理地址靠前的image 0启动失效就继续启动后面的image 1,多一层保障。

i.MX RT1170是区别于i.MX RT10xx的第二代架构,性能/功能更加强大,其在继承 i.MX RT10xx冗余程序启动的基础上,新增了双程序可交替启动设计,今天我们就来聊聊这个话题:

一、初识双程序可交替启动

与i.MX RT10xx一样,这里要聊的还是在一片挂载在FlexSPI上的串行NOR Flash里做冗余/双程序设计,就是下图中的image L和image H,不涉及LPSPI接口Flash B里的image 2。

“i.MX

先说跟i.MX RT10xx上一样的冗余程序启动流程,i.MX RT1170上电先启动物理地址靠前的image L,如果image L被破坏了,则继续启动image H。

什么是双程序可交替启动呢?简单说就是物理地址靠前的image L并不总是上电首先启动的image,在i.MX RT1170上新增了如下原型的image version启动头(在固定偏移 0x600 处),芯片上电 BootROM 会尝试判断两个 image L/H 里的 version 头版本,高版本的 image 优先被启动。这种设计方便了 OTA 升级。

Note: 当image L/H中均不含有效version启动头时(img_ver 等于 0xFFFFFFFF,或者高低16bit不符合取反关系),双程序可交替启动特性就不生效,此时等效于冗余程序启动,image L 永远被优先启动。

typedef struct
{
    uint16_t version;     // 版本值
    uint16_t inversion;   // version值的取反(~version)
} img_ver_t;

“i.MX

二、回顾冗余程序启动

在测试双程序可交替启动新特性之前,还是先过一下冗余程序启动。按照文章《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》第2节里一模一样的方法,在恩智浦官方MIMXRT1170-EVK开发板上做测试,这个板子FlexSPI1上挂了两片Flash,默认连接的16MB QuadSPI Flash,还有一片 64MB OctalFlash(需要做板子改动才能使能)。

在 i.MX RT1170 fuse 里关于冗余程序启动的使能位定义与i.MX RT10xx上差不多,只不过 fuse 地址从 0x6E0 换到了0xC80。还是跟之前测试一样借助MCUBootUtility工具将 FLEXSPI_NOR_SEC_IMAGE_OFFSET 烧录为 0x10,xSPI_FLASH_IMAGE_SIZE 保持默认 0,即第二份 image 偏移地址在 Flash 0x400000(4MB)处,最大 image 长度也是4MB。

“i.MX

继续用\SDK_2.11.0_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\led_blinky\cm7\iar\flexspi_nor_debug例程生成两个稍微不一样的 image,闪灯间隔时间一个是200ms(image L - iled_blinky_cm7_delay200ms.bin),另一个是 2s(image H - iled_blinky_cm7_delay2s.bin)。在 MCUBootUtility 工具主界面下使用 All-In-One 操作将 image L 下载进 Flash(baseaddress 设为 0x30000400),使用通用编程器界面 Write 操作将 image H 也下载进 Flash(Start 设为0x400400)。

现在Flash 里有了两份 image,当第一份 image 启动失败后,i.MX RT1170 BootROM 不是立刻去执行下一份 image ,还是那个取巧的方法,在一个软复位不置位的寄存器里(SRC_GPR10)标记当前状态,然后调用 NVIC_SystemReset() 重新进入 BootROM 执行。不过此时标记位从 GPR10[30] 换到了 GPR10[27:26],虽然是 2bit 状态,但设值 1/2/3 等效于设值 1,因为对于串行 NOR Flash 最多就是两份 image。这时候如果你想挂 J-Link 改写 SRC_GPR10 去做快速验证恐怕无法如愿,原因请看 《i.MX RT1170上用J-Link连接复位后PC总是停在0x223104》

“i.MX

所以在i.MX RT1170上只能老老实实做破坏 image 完整性的动作来验证冗余程序启动,经实测其效果与i.MX RT10xx 是完全一致的。

三、实测双程序可交替启动

现在我们开始实测双程序可交替启动,主要的工作量就是为 image L 和 image H 添加 version 启动头,并且将它们分别下载进 Flash。因为我们想验证物理地址靠后的 image H 比 image L 优先启动(冗余程序启动做不到这点),所以需要将 image H 的 version 头版本设高一点。

3.1 为 image 添加version 启动头

还是在\SDK_2.11.0_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\led_blinky\cm7\iar\flexspi_nor_debug例程基础上,首先在工程链接文件 MIMXRT1176xxxxx_cm7_flexspi_nor.icf 添加如下语句,指定 .img_ver 段的位置。

define symbol m_boot_img_ver_start           = 0x30000600;

place at address mem: m_boot_img_ver_start { section .img_ver };

然后在工程随便一个源文件里添加如下常量 s_bt_img_l_ver 定义,这个 image 闪灯间隔时间是 200ms(image L -iled_blinky_cm7_delay200ms_ver0.bin),版本是 0x0000(注意编译链接工程时为防止 s_bt_img_l_ver 被优化,可以在工程选项 Linker / Input /Keep symbols 里将其添加进去)。

const img_ver_t s_bt_img_l_ver @ ".img_ver" = {
    .version = 0x0000,
    .inversion = ~0x0000,
};

同样的工程,再生成另一个闪灯间隔时间为 2s(image H -iled_blinky_cm7_delay2s_ver1.bin) 的 image 时使用如下常量s_bt_img_h_ver 定义,版本是 0x0001。

const img_ver_t s_bt_img_h_ver @ ".img_ver" = {
    .version = 0x0001,
    .inversion = ~0x0001,
};

当然如果你嫌上述方法繁琐,也可以直接在最终 image binary 文件上做修改(注意 offset 位置一定要找对,i.MX RT1170 SDK XIP binary 文件起始数据对应 Flash 偏移是 0x400,因此文件中 0x200 处才对应 Flash 偏移 0x600):

“i.MX

3.2 下载含 version 头的image 进 Flash

现在需要借助 MCUBootUtility 工具的通用编程器功能分别将两个含 version 头的 image L/H 下载进 Flash。这里需要注意的是此时 image L 无法再通过主界面 All-In-One 操作来下载了,因为工具 v3.4 版本及以下没有对 version 启动头做识别处理,因此会丢掉 version 头数据(这个考虑会在 v4.0 之后加入支持)。

“i.MX

“i.MX

两个 image下载完成,一切工作就结束了,这时候你调整芯片启动模式到 2'b10 - Flash boot,给板卡重新上电,应该可以看到 image H 正在执行。

3.3 BootROM中判断version的逻辑

BootROM中关于 version 启动头是否有效以及版本高低判断逻辑其实是有一点复杂的,这里把具体代码分享给大家,方便大家为 image 设置有效的 version 头以及正确使能这个双程序可交替启动特性。

判断逻辑代码主要意思是仅当 image L 的版本不是 0xFFFFFFFF 且 image H 的版本是有效的(img_ver 高低16bit符合取反关系)情况下,如果 image L 版本无效或者 image L 版本有效但比 image H 版本低,则物理地址靠后的 image H 优先启动。除此以外其余情况,一律是物理地址靠前的 image L 优先启动。

uint32_t image_l_base = FlexSPIx_AMBA_BASE
uint32_t image_h_base = FlexSPIx_AMBA_BASE + FLEXSPI_NOR_SEC_IMAGE_OFFSET

uint32_t get_image_index(void)
{
    uint32_t redundant_boot = ((SRC->GPR[9] & 0x0C000000) >> 26);

    static uint32_t image_index[] = { 0, 0 };
    img_ver_t image_l_version = *(img_ver_t *)(image_l_base + 0x600);
    img_ver_t image_h_version = *(img_ver_t *)(image_h_base + 0x600);
    if ((image_l_version.version != 0xFFFFu || image_l_version.inversion != 0xFFFFu) &&
        ((0xFFFFu & image_h_version.version) == (0xFFFFu ^ image_h_version.inversion)) &&
        ((0xFFFFu & image_l_version.version) != (0xFFFFu ^ image_l_version.inversion) || (image_l_version.version < image_h_version.version)))
    {
        image_index[0] = 1;
    }
    else
    {
        image_index[1] = 1;
    }

    return image_index[redundant_boot];
}

痞子衡在MIMXRT1170-EVK 开发板上对image 版本设置情况也做了比较全面的实测,测试结果如下:

“i.MX

四、一些关于image的注意事项

1)虽然文中所有的测试均是针对 XIP image,但这个冗余程序/双程序可交替启动特性对于 Non-XIP image 也同样适用。

2)如果是 XIP image,其链接地址不一定要固定在偏移 0x2000 处,因为 IVT 的存在,其是可以链接在偏移 0x2000 之后的任意位置的。

3)如果是 Non-XIP image,在 SDK 包里无法直接生成含启动头的 Non-XIP image binary,这时候可以先使用 MCUBootUtility 主界面的 All-In-One 操作下载一次 image,再通过通用编程器界面 Read 操作读回来便是含启动头的 Non-XIP image binary。

相关阅读
《i.MX RT1060/1010上串行NOR Flash冗余程序启动设计》

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

围观 73

华邦新型 1.2V SpiFlash 产品W25Q64NE提供高存储容量,可满足TWS耳机和健身手环等新一代无线消费类电子设备的内存需求

全球半导体存储解决方案领导厂商华邦电子今日宣布,推出全新SpiFlash® 产品W25Q64NE ,首次将1.2V SPI NOR Flash容量扩展至64Mb。华邦新型W25Q64NE闪存可提供更多代码存储空间并减少设备的运行功耗,充分满足新一代智能可穿戴设备和移动设备的内存需求。

“华邦电子扩展其存储容量,推出全新超低功耗64Mb

华邦是第一家推出 1.2V SPI NOR Flash的闪存制造商,该产品工作电压的扩展范围是1.14V-1.6V,可兼容单节 AA型碱性电池的输出电压。此次将产品容量提升至64Mb,华邦 1.2V NOR Flash系列产品可满足智能设备对代码存储空间的更高要求。目前,新型 W25Q64NE产品已经送样,同时提供符合行业标准封装的USON8-3x4和WLCSP小尺寸封装形式。

产品特点

通常,移动设备和可穿戴设备的总功耗有99%都是在运行模式中产生,与1.8V SpiFlash产品相比,华邦1.2V SPI NOR Flash可将Flash本身的运行功耗减少三分之一。因此,使用华邦的 1.2V NOR Flash可帮助电池容量较小的设备如TWS耳机与健身手环大幅延长产品续航时间。

华邦表示:“如今,电池续航时间已经成为影响消费者购买TWS耳机和智能手表等新产品的关键因素,而华邦新型W25Q64NE闪存正是这些设备制造商的理想选择,可助力提高终端产品竞争力。”

在工作频率为 50MHz 的读取模式下,1.8V SpiFlash 内存的工作电流为 4mA,功耗为 7.2mW。而同样在50MHz时,华邦1.2V SpiFlash内存的工作电流也为4mA,但功耗仅为 4.8mW。使用1.2V SpiFlash替换1.8V产品,可立即节省33%的功耗。

除省电外,1.2V SpiFlash还可简化系统设计并降低成本。随着 SoC工艺向更先进的制程发展,新一代 SoC 的 I/O 电压正在逐步降低,目前已经低于1.8V,因此需要搭配电平转换器才能与传统的 1.8V/3V SPI Flash连接,这将导致额外的成本支出并增加系统设计的复杂性。而采用1.2V 闪存,SoC 无需电平转换器即可直接连接到 SPI Flash,从而降低 BOM 成本和 PCB 占用空间。

华邦W25Q64NE配备性能出色的标准SPI NOR 接口,最大数据传输速率可达 42MB/s。与1.8V/3V SPI Flash操作方式的架构相同,支持最小4KB的可擦除扇区。

欲了解更多产品信息,请访问华邦电子官网:www.winbond.com

关于华邦

华邦电子为全球半导体存储解决方案领导厂商,主要业务包含产品设计、技术研发、晶圆制造、营销及售后服务,致力于提供客户全方位的利基型内存解决方案。华邦电子产品包含利基型动态随机存取内存、行动内存、编码型闪存和TrustME®安全闪存,广泛应用在通讯、消费性电子、工业用以及车用电子、计算机周边等领域。华邦总部位于中国台湾中部科学园区,在美国、日本、以色列、中国大陆及香港地区、德国等地均设有公司服务点。华邦在中科设有一座12寸晶圆厂,目前并于南科高雄园区兴建新厂,未来将持续导入自行开发的制程技术,提供合作伙伴高质量的内存产品。

围观 14

MM32系列微控制器为用户提供了丰富的选择,可适用于工业控制、智能家电、建筑安防、医疗设备以及消费类电子产品等多方位嵌入式系统设计。在某些应用中,需要较大容量的存储空间用于存储数据;这时可以通过SPI 外扩NOR Flash,NAND Flash, 或者通过SDIO扩展SD Card或TF-Card。但有些需要高速存储数据,上述方式还是不够快速,这时可以使用MM32F3270系列的FSMC来外扩并行NOR Flash来实现。

并行NOR Flash与并行SRAM和PSRAM的读写接口大部分相同,但NOR Flash的写入速度与SRAM和PSRAM比较,相对较慢,需要通过NWAIT 信号检查NOR Flash的操作状态,并做一些等待,相应的时序需要根据不同的NOR Flash芯片所规定的参数而做相应的设置即可。

本文接下来就使用MM32F3270外挂S29GL128P NOR Flash芯片来演示FSMC对NOR Flash芯片的设置与读写。

前文已经介绍了MM32F3270的FSMC的接口功能与特色。结合MM32F3270 的FSMC外部接口信号,可使用异步方式访问NOR Flash,可以选用复用或非复用方式扩展NOR Flash,还可以通过配置实现外扩8位总线或16位总线接口的NOR Flash。

“表1:FSMC控制器外部信号"
表1:FSMC控制器外部信号

MM32F3270系列MCU因为封装的原因,导致只有部分MCU产品可以通过硬件复用出全部或部分的FSMC接口的相关GPIO;外扩NOR Flash也只有使用 LQFP144引脚封装MCU芯片才能支持连接地址数据非复用和复用方式外扩并行NOR Flash;而LQFP100引脚封装芯片因地址线缩减,仅支持连接地址数据复用方式外扩并行NOR Flash。LQFP64因为无法引出足够的地址与数据总线,同样不支持外扩并行NOR Flash。

“表2:MM32F3270不同封装芯片与NOR
表2:MM32F3270不同封装芯片与NOR Flash接口

目前市场上非复用型16位数据总线接口的NOR Flash也是较为普遍,下面针对非复用方式,介绍MCU与NOR Flash的硬件原理图设计和软件寄存器配置。

在此用MM32F3270的FSMC接口扩展S29GL128P NOR Flash,其原理框图如下:

“图1:NOR
图1:NOR Flash原理框图

S29GL128P的数据按 16 位的Half Word寻址,容量128M Bit, 16M字节,从芯片手册中可以查询到S29GL128P的引脚功能描述如下:

“表3:NOR
表3:NOR Flash引脚信号

S29GL128P可以通过CS, OE, WR, WP#, RY/BY#控制电路,结合Address与Data I/O实现对NOR Flash的读写操作。

1、FSMC非复用方式控制NOR Flash的硬件设计

“表4:NOR
表4:NOR Flash数据, 地址, 读写信号与MCU接口的引脚说明

外部设备地址映像从FSMC的角度看,FSMC外扩寻址空间用于访问最多4个FSMC地址映射空间,可以用于访问4个NOR闪存或SRAM/PSRAM存储设备,并对应的有4个专用的片选FSMC_NE[4:1]。

外部存储器划分为固定大小为64M字节的四个存储块,见下图。

“使用MM32F3270

存储区块与片选信号对应关系:

“使用MM32F3270

HADDR是需要转换到外部存储器的内部AHB地址线。HADDR[25:0]包含外部存储器地址。HADDR是字节地址,而存储器访问不都是按字节访问,因此接到存储器的地址线依存储器的数据宽度有所不同,如下表:

“使用MM32F3270

对于16位宽度的外部存储器,FSMC将在内部使用HADDR[25:1]产生外部存储器的地址FSMC_A[24:0]。不论外部存储器的宽度是多少(16位或8位),FSMC_A[0]始终应该连到外部存储器的地址线A[0]。

根据外部NOR Flash设计原理图:

“使用MM32F3270

2、FSMC非复用方式控制NOR Flash的程序设计

根据配置的接口电路配置GPIO初始化程序与FSMC初始化程序。

void FSMC_NOR_Init(void)
{
    FSMC_InitTypeDef  FSMC_InitStructure;
    FSMC_NORSRAM_Bank_InitTypeDef  FSMC_BankInitStructure;

    FSMC_NORSRAM_BankStructInit(&FSMC_BankInitStructure);
    FSMC_NORSRAMStructInit(&FSMC_InitStructure);
    RCC_AHB3PeriphClockCmd(RCC_AHB3ENR_FSMC, ENABLE);

    FSMC_BankInitStructure.FSMC_SMReadPipe    = 0;
    FSMC_BankInitStructure.FSMC_ReadyMode     = 0;
    FSMC_BankInitStructure.FSMC_WritePeriod   = 15;
    FSMC_BankInitStructure.FSMC_WriteHoldTime = 3;
    FSMC_BankInitStructure.FSMC_AddrSetTime   = 3;
    FSMC_BankInitStructure.FSMC_ReadPeriod    = 15;
    FSMC_BankInitStructure.FSMC_DataWidth     = FSMC_DataWidth_16bits;
    FSMC_NORSRAM_Bank_Init(&FSMC_BankInitStructure, \
    FSMC_NORSRAM_BANK1);

    FSMC_InitStructure.FSMC_Mode = FSMC_Mode_NorFlash;
    FSMC_InitStructure.FSMC_TimingRegSelect = FSMC_TimingRegSelect_0;
    FSMC_InitStructure.FSMC_MemSize = FSMC_MemSize_64MB;
    FSMC_InitStructure.FSMC_MemType = FSMC_MemType_FLASH;
    FSMC_InitStructure.FSMC_AddrDataMode = FSMC_AddrDataDeMUX;
    FSMC_NORSRAMInit(&FSMC_InitStructure);
}

GPIO初始化

void FSMC_GPIO_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_StructInit(&GPIO_InitStructure);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
    RCC_AHBPeriphClockCmd(RCC_AHBENR_GPIOB | RCC_AHBENR_GPIOC | \
    RCC_AHBENR_GPIOA | RCC_AHBENR_GPIOD | RCC_AHBENR_GPIOE | \
    RCC_AHBENR_GPIOF | RCC_AHBENR_GPIOG, ENABLE);

    GPIO_PinAFConfig(GPIOD, GPIO_PinSource4, GPIO_AF_12);  //NOE
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource5, GPIO_AF_12);  //NWE
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource6, GPIO_AF_12);  //NWAIT
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource11, GPIO_AF_12); //A16
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource12, GPIO_AF_12); //A17
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource13, GPIO_AF_12); //A18
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource14, GPIO_AF_12); //D0
    GPIO_PinAFConfig(GPIOD, GPIO_PinSource15, GPIO_AF_12); //D1
    //省略部分代码
    GPIO_PinAFConfig(GPIOF, GPIO_PinSource0, GPIO_AF_12);  //A0
    GPIO_PinAFConfig(GPIOF, GPIO_PinSource1, GPIO_AF_12);  //A1
    GPIO_PinAFConfig(GPIOF, GPIO_PinSource2, GPIO_AF_12);  //A2
    GPIO_PinAFConfig(GPIOF, GPIO_PinSource3, GPIO_AF_12);  //A3
    //省略部分代码
    GPIO_InitStructure.GPIO_Pin  =  GPIO_Pin_All;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_Init(GPIOD, &GPIO_InitStructure);

    GPIO_InitStructure.GPIO_Pin  =  GPIO_Pin_6;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_FLOATING;
    GPIO_Init(GPIOD, &GPIO_InitStructure);

    //省略部分代码

}

从选择的片选信号与FSMC外扩存储映像空间可以得出Bank2地址为0x64000000,使用该地址作为读写外部NOR Flash的基地址。

#define NOR_FLASH_START_ADDR       ((u32)0x64000000)
#define NOR_FLASH_END_ADDR         ((u32)0x67FFFFFF)
//读一个半字
u16 FSMC_NOR_ReadHalfWord(u32 ReadAddr)
{
    NOR_WRITE(ADDR_SHIFT(0x00555), 0x00AA);
    NOR_WRITE(ADDR_SHIFT(0x002AA), 0x0055);
    NOR_WRITE((NOR_FLASH_START_ADDR + ReadAddr), 0x00F0 );
/* exit autoselect (write reset command) */
    return (*(vu16*)((NOR_FLASH_START_ADDR + ReadAddr)));
}
//连续读一块半字数据
void FSMC_NOR_ReadBuffer(u16* pBuffer, u32 ReadAddr, u32 NumHalfwordToRead)
{
    NOR_WRITE(ADDR_SHIFT(0x0555), 0x00AA);
    NOR_WRITE(ADDR_SHIFT(0x02AA), 0x0055);
    NOR_WRITE((NOR_FLASH_START_ADDR + ReadAddr), 0x00F0);
/* exit autoselect (write reset command) */
    for(; NumHalfwordToRead != 0x00; NumHalfwordToRead--) {
        // Read a Halfword from the NOR
        *pBuffer++ = *(vu16*)((NOR_FLASH_START_ADDR + ReadAddr));
        ReadAddr = ReadAddr + 2;
    }
}

读写外部NOR Flash与读写外部SRAM的操作,地址寻址方式是一样的,但NOR Flash的写数据有较大的不同。

以单个Word编程为例,如下为写单个Word的流程图与实现代码:

“使用MM32F3270
NOR_Status FSMC_NOR_WriteHalfWord(u32 WriteAddr, u16 Data)
{
    NOR_WRITE(ADDR_SHIFT(0x0555), 0x00AA);
    NOR_WRITE(ADDR_SHIFT(0x02AA), 0x0055);
    NOR_WRITE(ADDR_SHIFT(0x0555), 0x00A0);
    NOR_WRITE((NOR_FLASH_START_ADDR + WriteAddr), Data);

    return (FSMC_NOR_GetStatus(Program_Timeout));
}

通过MindMotion的官网下载MM32F3270 lib_Samples:

https://www.mindmotion.com.cn/products/mm32mcu/mm32f/mm32f_mainstream/mm32f3270/

工程路径如下:

~MM32F327x_Samples\LibSamples\FSMC\FSMC_NOR\

可以看到详细的样例与功能操作。

下章的题目为《使用MM32F3270 的FSMC驱动外部OLED》讲解通过FSMC外扩并口OLED的实现。

来源:灵动MM32MCU
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 33
  • 提供高兼容性的设计,在任一平台需要扩充内存容量时,客户无须更改硬件设计就可将其存储代码的闪存容量从16Mb扩展到2Gb
  • 多个不同领域的全球领先客户,已经开始采用华邦全新的512Mb NOR Flash进行小批量产。性能得到验证,并预计将于2021年下半年量产
  • 采用华邦的内部设计(in-house design)和制造能,可确保为全球客户提供批量供应及持续支援

“华邦推出全新1.8V

华邦电子今日宣布,推出全新1.8V 512Mb SPI NOR闪存,可支持高达166MHz的标准SPI,Dual-SPI,Quad-SPI时钟速率。华邦全系列SPI NOR 闪存,在相同封装上的脚位皆彼此兼容。为了提供客户更完整的选择方案,除了原有的3V 512Mb W25Q512JV外,华邦新推出的W25Q512NW SPI NOR闪存,让客户轻松使用更高容量的存储空间,同时无须修改PCB设计。通过搭载W25Q512NW,客户不仅能够延长产品平台的使用周期,加快产品上市时间,节省开发新产品所需时间和精力,同时借助使用单一的闪存平台,客户还可以扩展自身未来的产品路线图。

华邦表示:“W25Q512NW SPI NOR闪存能够满足新兴的5G应用对高品质与高容量的需求,再搭配华邦全球销售网及灵活、快速、稳定的供货能力,华邦可满足客户从最低到最高闪存容量的最佳选择。”

W25Q512NW 的目标市场与产品优势

W25Q512NW支持166MHz SDR与80MHz DDR高速读取,并且搭配QPI模式可以大幅满足XIP (eXecute In Place)以及实时启动(instant-on)的需求。华邦推出的512Mb SPI NOR闪存容量还可由2或4颗芯片堆叠成1Gb和2Gb闪存,可为客户提供弹性更优的读写并行(Read-While-Write)功能,对于日渐广泛采用的OTA (Over-The-Air) 应用来说,可以达到快速而且稳定的固件更新。

对于5G调制解调器、5G边缘计算、云端服务器、光通讯调制解调器和智能化物联网装置等各种不同应用的客户来说,程序代码容量需求平均每两年会提高2倍,而W25Q512NW的兼容性可以帮助原始设备制造商(OEM)软件团队在开发具有更多新功能的应用程序代码时,不会受到闪存容量的限制。

关于华邦

华邦电子为全球半导体存储解决方案领导厂商,主要业务包含产品设计、技术研发、晶圆制造、营销及售后服务,致力于提供客户全方位的利基型内存解决方案。华邦电子产品包含利基型动态随机存取内存、行动内存、编码型闪存和TrustME®安全闪存,广泛应用在通讯、消费性电子、工业用以及车用电子、计算机周边等领域。华邦总部位于中国台湾中部科学园区,在美国、日本、以色列、中国大陆及香港地区、德国等地均设有公司服务点。华邦在中科设有一座12寸晶圆厂,目前并于南科高雄园区兴建新厂,未来将持续导入自行开发的制程技术,提供合作伙伴高质量的内存产品。

围观 54

作者: 电子创新网张国斌

TWS耳机、机顶盒、笔记本、平板、汽车仪表盘、5G基站、AMoled显示屏、路由器、医疗电子设备、物联网设备.....这一长串设备都需要一个关键的小器件--NOR Flash,这个小器件的缺货可能导致杀伤力很大,因为没有这个小器件,这一长串设备就面临停工的危险!

近日,NOR Flash龙头台湾旺宏说NOR Flash交期竟然要达2年!这让很多业者恐慌,NOR Flash供应未来将如何?在2021年慕尼黑上海电子展上,我们采访了兆易创新存储器事业部市场经理薛霆,他分享了兆易创新对NOR Flash未来走势的看法。

“”

“兆易创新的Flash目前全部产品线都已经过渡到55nm新工艺,我们已经推出了一系列从最小容量512Kbit到最大容量2Gbit的全系列的SPI NOR Flash。我们是全球第一家把SPI NAND Flash推向世界而且量产的公司。”他强调,“3年前我们开始推动55nm工艺研发,经过3千片以上wafer的磨合,把55nm做到了可以大规模量产。我们55nm的产品第一,工艺上更先进,每一颗的体积更小,功耗上也比65nm降低了30%左右。从功耗到面积都带来了更多的节省,给客户也带来了更有性价比的产品。”

他表示大量设备都要用到NOR Flash,如PC、笔记本、服务器、智能网卡、BMC基板管理设备等。AR眼镜也需要用到一颗Flash去存储这些关键数据。

“今年,2020版智能电表开始大量上市,这里面也都需要用到可靠性非常高的NOR Flash,新颁布的电表要求第一,它对用电的记录数据量更大了,每几分钟就要存用户用电数据量。国家电网的目的就是希望它以后可以分析你每家每户怎么用电、省电,甚至什么电器最耗电,这是它的终极目标。它对电表的要求越来越智能化,伴随这种智能化,就需要更多更可靠性的存储芯片去存储本地的数据,做程序的管理。还有包括一些通讯应用。”他解释说,“伴随着整个世界进入到SOHO模式,网络通讯带宽越来越大了,也需要更多5G基站,大量的基站也需要用到SPI NOR Flash,这需要至少10万次擦写、20年数据保证时间。室外基站都是很高的温度下,需要一些高可靠性的连续工作十年以上的 NOR Flash,这个正好是我们公司擅长的。我们与国际和国内一些基站客户都在紧密地合作。”

在TWS耳机方面,他指出目前TWS耳机上有很多新兴的应用,包括心率、心电、语音唤醒都已经出现了,这意味着对Flash容量的需求越来越大。此外,大量物联网设备也需要用到NOR Flash。

关于NOR Flash产能,他指出兆易创新一直在和供应链保持紧密的合作关系,“实际上产能的扩充需要很长的周期,至少18个月,涉及裸晶圆、设备,进厂以后还要调试,良率到一定阶段才能真正量产。但是我们用的这些生产芯片的设备都是很高精尖的,里面也需要芯片,从上游的晶圆到下游的供应链、封装测试,每一个环节的设备都呈现紧张的状态,同时客户的需求在猛烈增长,也需要较长的一段时间才能逐步地满足现在客户这么旺盛的需求。”他强调,“我们的出货量还在稳步上升。但我们发现虽然我们出货量还在稳步上升,但是客户需求比我们上升得还快。一年前我们就开始布局产能扩充,但是一年前没有想到会发生疫情,目前Flash这块有3个工厂都在支持我们的产能,去年下半年开始他们都在不断地进行产能上的调配。我们的产能还是在逐步缓慢上升中,预计我们的排名还会上升!”

他透露大量海外知名客户,尤其工业类的应用包括电力、车载客户,也开始找兆易合作了,兆易今年的目标是把55nm做扎实,把各种容量、规格做全。“Flash产品的特点就是很散,需求很多样化,一定要把各种规格做全。”他指出。

围观 54
订阅 RSS - NOR Flash