恩智浦

恩智浦携手合作伙伴提供多种扩展板,以补充我们的通用MCU,且产品清单不断增加。因此,我们创建了Expansion Board Hub (EBH),我们将有关每个扩展板的板概述、软件、支持和其他有用信息的链接放在名为NXP EBH的平台上。 了解EBH平台详情>>   

EBH中的所有产品均受与MCUXpresso SDK兼容的软件支持,这些软件由恩智浦或相关合作伙伴提供。

Expansion Board Hub是什么?

如您所知,我们的扩展板为我们的评估套件 (EVK) 添加了Wi-Fi、传感器、接口和其他功能。恩智浦EBH是我们扩展恩智浦评估板功能的展示平台,包含恩智浦提供的扩展板以及我们的合作伙伴提供的软件和产品支持的链接。

有关Expansion Board Hub在线工具展示的扩展板及提供的软件支持,点击了解详情>> 

1.jpg

图1:恩智浦EBH接口

EBH的主要特性和优势

我们为客户和合作伙伴创建了恩智浦EBH。对于我们的客户而言,目的是在一个地点展示评估板的各种扩展可能性,对于我们的合作伙伴而言,EBH允许他们展示自己的产品。

我们希望为客户提供直观、用户友好的体验,让他们尽情探索扩展我们的各种评估板可实现目标的无限可能。EBH为方便客户提供了一套完备的可用扩展板;但它不仅仅是一个产品清单。我们设计的这款工具拥有全文搜索功能以及筛选选项,可按供应商、连接器类型和/或类别(如生物特征识别、传感器、存储)的任意组合进行筛选。

2.jpg
图2:恩智浦EBH上提供几种不同的筛选器设置

找到您感兴趣的扩展板后,只需点击便可看到其功能和基本规格的概要介绍,示例如下所示。本概述还提供有关更多规范的链接、对软件和硬件支持资源的访问以及产品卡的链接。请注意,产品卡的链接可以与同事共享。

3.jpg

图3:客户可以访问有关扩展板、产品页面和产品卡的链接

我们的合作伙伴将向我们提供有关其产品的详细信息,以及对您有帮助的链接。这样他们便能够在易于搜索的界面中展示自己的产品。随着我们不断添加新的供应商、合作伙伴和产品,客户将能够轻松找到他们的最新产品。

将搜索和筛选功能与产品信息相结合,打造一个用户友好、信息丰富的市场,帮助客户找到他们需要的解决方案,为他们提供支持,帮助他们实现产品的最大价值。

了解更多信息

恩智浦Expansion Board Hub提供流畅的体验,您可以轻松访问产品信息,并为我们不断增长的扩展板产品组合提供支持。请立即联系我们,了解您和您的设计可获得哪些好处。获取更多信息,您也可以访问NXP EBH官网>>图片

本文作者

1677209466148703.jpg

Patrik Fillner,恩智浦安全互联边缘生态系统团队技术营销工程师。在担任此职务期间,他根据恩智浦的创新产品及客户需求反馈,制定针对配置工具和MCU原型制作使能工具的营销战略。他积极追寻新的技术趋势,为MCUXpresso软件和工具套件用户提供最佳体验。Patrik毕业于布尔诺理工大学,获得了微电子学和半导体研究硕士学位。

来源:NXP客栈

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

围观 10

前段时间有客户在官方社区反映i.MX RT1170下,使用官方SDK里FlexSPI驱动去擦写Flash时不能很好地支持全局中断。

客户项目里用了两块NOR Flash,分别挂在不同的 FlexSPI上,一块Flash用于存储XIP代码(FlexSPI1),另一块Flash用于存储项目资源数据(FlexSPI2),显然这样的设计原理上是没有问题的,那为什么使能了中断会出问题呢?今天就来分析下这个问题:

注: 客户测试的SDK版本为 2.12.1,对应的FlexSPI driver版本为2.3.6

一、为什么擦写Flash时经常需要关全局中断?

在具体分析客户问题之前,我们先来聊聊嵌入式应用里应对NOR Flash的擦写,为何大部分情况下都是要关闭全局中断(这里假设执行代码空间与擦写操作空间在同一个 Flash上,当然是在不同区域),这其实跟如下两个特性有关:

1.1 RWW特性(Read-While-Write)

RWW特性的意思是在Flash执行擦写命令进入Busy 状态期间(Flash内部状态寄存器 WIP位变状态1)还能否继续响应非操作区域的读访问。如果SR[WIP] = 1 时还能够支持读访问,则该Flash 支持RWW,反之则不支持RWW。

1.png

绝大部分Flash都是不支持RWW特性的,这就是为什么Flash擦写操作代码本身是需要重定向到RAM里去执行(尤其是回读SR[WIP]状态的代码)。

对于支持RWW特性的Flash,一般是以Block为单位,Flash擦写操作代码放在BlockX 里执行,则可以操作BlockX以外的其它Block 区域,且不需要做代码重定向。

现在你应该知道对于不支持RWW的Flash为什么擦写时需要关闭全局中断了,因为无法保证中断响应相关代码全都重定向到RAM里了,所以干脆在Flash擦写期间不响应任何中断。

1.2 SCLK Stop特性

SCLK Stop特性的意思是在Flash执行写入命令接受主设备传输过来的Page数据期间,如果总线上SCLK停止(一般情况是FlexSPI这一端的TXFIFO为空或者触发空条件),则Flash能否也暂停接受当前Page数据直到SCLK继续输出从而继续处理剩下的Page数据。

绝大部分Flash是不支持SCLK Stop特性的,因此在MCU端如果传输Page数据,需要一次性连续传输完成,一旦中途被打断,则两次不连续的Page数据传输可能无法得到想要的Page写入结果。这也是为何Flash写入期间我们需要关闭中断。

二、FlexSPI外设写操作设计

关于i.MX RT上的FlexSPI外设基本情况,以前有两篇旧文 《FlexSPI支持在Flash XIP原理》、《FlexSPI支持AHB方式写入Flash》,大家先读一下有个初步了解。

这里想重点说一下FlexSPI关于IPG方式写操作的设计,下图为FlexSPI外设的模块框图,绿色线标出了 IPG 方式写入的通路,这里大家可以看出,其中 IP_TX_FIFO 模块起了重要的数据缓冲作用,驱动里往 FLEXSPI->TFDRx 寄存器写入的 Page 数据会先被装载进 IP_TX_FIFO 里,然后再传输出去。

2.png

不同i.MX RT型号中IP_TX_FIFO大小不一样,目前有三种大小:128、256或1024 Bytes。

对于QuadSPI/OctalSPI NOR Flash来说,Page 大小一般是256 Bytes;对于 HyperBus Flash,Page 大小一般是 512 Bytes。所以在 i.MX RT10xx 上 IP_TX_FIFO 是不足以缓冲整个 Page 的,i.MX RT117x 上可以缓冲 QuadSPI/OctalSPI NOR 类型的 Page,i.MX RT118x/5xx/6xx 上则可以缓冲全部 NOR Flash 类型的 Page。

对于 Page 数据不能全部缓冲的情况,则需要一边传输一边缓冲。

3.png

在具体装载数据进 IP_TX_FIFO 时,主要涉及如下三个 FLEXSPI 寄存器,IP_TX_FIFO 一次只能被填入watermark level大小的数据,想要把全部 Page 数据填进 IP_TX_FIFO,需要分多次装载。只要 FLEXSPI->INTR[IPTXWE] 标志为 0, 即代表 IP_TX_FIFO 剩余空间大于等于 watermark level,那么就可以继续装载。

  • FLEXSPI->IPTXFCR[TXWMRK]  -- 设置一次装载进 IP_TX_FIFO 的数据长度(即 watermark level),8 Bytes为单位
  • FLEXSPI->TFDRx            -- 按 watermark level 长度填入 IP_TX_FIFO 装载数据
  • FLEXSPI->INTR[IPTXWE]     -- 触发 IP_TX_FIFO 的一次装载

4.png

三、客户问题及FlexSPI driver写操作流程

前面铺垫了这么多,终于来到客户遇到的 FlexSPI 驱动对于中断不支持的问题了。因为客户使用了两片Flash,所以不存在 RWW 限制问题,那剩下的原因就跟 SCLK Stop 特性有关,即 IP_TX_FIFO 并没有缓冲全部的 Page,导致 Page 传输过程被中断打断了,然后 IP_TX_FIFO 因为缓冲数据全部发完而使 FlexSPI 模块进入了 SCLK Stop 状态。

我们直接打开fsl_flexspi.c驱动文件,找到跟写操作相关的 FLEXSPI_TransferBlocking() 函数,在函数实现里可以发现,启动写传输时序的控制位 FLEXSPI->IPCMD[TRG] 是在 IP_TX_FIFO 填充动作 FLEXSPI_WriteBlocking() 函数之前被开启的,那这样的实现确实是不能够很好地支持中断的。

5.png

四、如何改进FlexSPI driver支持中断?

知道了原因所在,改起来也很简单。如果是QuadSPI/OctalSPI NOR Flash类型(Page=256 Bytes),在 i.MX RT117x 上,其 IP_TX_FIFO 大小为 256 Bytes,能够缓冲全部的 Page 大小,则可以先调用 FLEXSPI_WriteBlocking() 装载全部的 Page 数据,然后再开启 FLEXSPI->IPCMD[TRG] 去触发写传输时序,这时候就不怕被中断打断了,如下代码所示。

当然下面代码只是一个 workaround 式的实现示例,不是一个完整的解决方案,毕竟 FlexSPI 驱动要适配全部 i.MX RT 型号以及全部类型的 NOR Flash,此外还适用 NAND 型 Flash(Page 一般是 2KB),这时候需要根据情况拆分调用多次 FLEXSPI_WriteBlocking() 函数(不管怎样要保证启动写传输时序前,把 IP_TX_FIFO 先装满)。

status_t FLEXSPI_TransferBlocking(FLEXSPI_Type *base, flexspi_transfer_t *xfer)
{
    // 代码略去

    /* Start Transfer. */
    if ((xfer->cmdType == kFLEXSPI_Write) || (xfer->cmdType == kFLEXSPI_Config))
    {
        result = FLEXSPI_WriteBlocking(base, xfer->data, xfer->dataSize);
        base->IPCMD |= FLEXSPI_IPCMD_TRG_MASK;
    }
    else if (xfer->cmdType == kFLEXSPI_Read)
    {
        base->IPCMD |= FLEXSPI_IPCMD_TRG_MASK;
        result = FLEXSPI_ReadBlocking(base, xfer->data, xfer->dataSize);
    }
    else
    {
        base->IPCMD |= FLEXSPI_IPCMD_TRG_MASK;
    }

    // 代码略去
}

来源:恩智浦MCU加油站

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

围观 47
  • RW612是恩智浦首款安全三频无线电MCU,集成i.MX RT跨界MCU,支持MatterTM标准(包括Matter over Wi-Fi®、Matter over Thread®和Matter over Ethernet),以简化智能家居设备的设计

  • 全新K32W148无线MCU具有先进的处理能力,支持Thread、Matter、Bluetooth®和Zigbee®等多协议,适用于创建可扩展的智能家居解决方案 

  • 两款芯片均包含在恩智浦EdgeLock® Assurance计划中,可提供EdgeLock 2GO服务,支持密钥和证书管理。 

恩智浦半导体(NXP Semiconductors N.V.,)今天宣布推出全新产品组合,助力简化物联网和工业物联网解决方案开发。恩智浦不断扩展端到端Matter解决方案的产品组合,RW612和K32W148兼具先进的边缘处理功能和内置安全性,可简化支持Matter的智能家居设备的开发流程与设计,并降低成本。

近期推出的Matter标准由连接标准联盟(CSA)开发,旨在简化智能家居中设备的互操作性。该联盟由包括恩智浦在内的行业领导者组成Matter的目的是让来自不同品牌、不同生态系统的设备能够实现无缝且安全可靠的通信,进而使消费者摆脱生态系统的约束。有了这一创新举措,消费者可以根据所需的功能选择设备,而不是根据复杂或令人困惑的连接要求选择设备。恩智浦K32W148支持Matter及其他协议,而RW612的三频无线电功能让开发人员能够轻松将Matter功能集成到智能家居设备中。

RW612是恩智浦首款同时支持Wi-Fi® 6、Bluetooth® Low Energy 5.3和802.15.4等多协议、能够支持Thread或Zigbee的三频无线电MCU,面向智能家居设备,如温控器、车库门开启器、门锁、IP摄像头、机器人吸尘器以及智能家电应用。

K32W148无线MCU可为智能插座、智能照明、低功耗智能设备和传感器等设备提供跨Thread、Bluetooth Low Energy 5.3和Zigbee的多协议支持,还能够为家庭路由器、集线器和桥接器轻松添加Thread和Zigbee支持。多协议支持能力可降低成本,可简化天线设计(只需单天线)。

恩智浦半导体副总裁兼无线连接解决方案总经理Larry Olivas表示:“下一代消费设备和工业设备需要集先进的MCU与跨Thread、Wi-Fi、Bluetooth和Matter等重要协议的安全连接于一体。恩智浦结合先进的边缘处理能力、领先的三频无线电产品组合以及先进的安全性,可简化设计流程,降低支持Matter的复杂性,帮助智能设备厂商更快地将创新的下一代产品推向市场。”

三频无线电简化智能家居设备开发

RW612集成了EdgeVerse™ i.MX RT跨界MCU系列,具备三频无线电和先进的边缘处理能力。它还搭载Arm® Cortex®-M33 MCU子系统,带有TrustZone®-M,集成Wi-Fi 6、Bluetooth LE 5.3和802.15.4,支持Thread或Zigbee。该MCU集成度高,可降低设计复杂性、BOM成本和解决方案尺寸,包括片上SRAM和高性能可配置外设,例如以太网、LCD控制器和五个FlexComm模块,支持多种串行协议。RW612受统一MCUXpresso®开发环境的支持,帮助简化开发进程,缩短上市时间。

恩智浦还提供同系列的RW610,支持Bluetooth LE Audio和AuracastTM广播音频等新功能,适用于以音频应用,如便携式音频设备和扬声器、家庭影院系统和游戏控制器。

适用于支持Matter的智能家居的无线MCU 

多协议K32W148无线MCU的架构采用独立无线电和安全执行环境的设计,Arm®Cortex®-M33主核和存储器可供客户应用使用。多协议无线电支持Matter、Thread、Bluetooth LE 5.3和Zigbee。此外还包括双PAN功能,可用于简化多个IEEE 802.15.4网络(如Thread和Zigbee)的共存。K32W148受统一MCUXpresso开发环境的支持,帮助简化开发进程,缩短上市时间。

安全性是Matter支持的核心

K32W148和RW61x无线MCU均加入了恩智浦EdgeLock Assurance计划,遵循“设计确保安全”思路,包括防御远程和本地软件攻击,支持具有不可变信任根、硬件加速加密的安全启动、安全调试和安全无线固件更新,以及生命周期管理。此外它们还经过优化,可以与EdgeLock SE05x安全芯片和EdgeLock A5000安全身份验证器实现无缝协作。这两款分立式安全组件可选预插入密钥和证书,可提供经过通用标准EAL6+认证的全套插入式解决方案,带来额外的防篡改保护,并支持额外的安全用例(如设备完整性保护或安全UWB测距)。这两款器件还支持恩智浦EdgeLock 2GO服务,可用于简化从制造直到整个设备生命周期的设备证书配置和管理。

RW612和RW610目前可提供样片。更多详细信息,请访问NXP.com/RW612或联系全球恩智浦销售代表。 

K32W148目前可提供样片。更多详细信息,请访问NXP.com/K32W148或联系全球恩智浦销售代表。

有关恩智浦端到端Matter解决方案详情,请访问nxp.com/Matter

围观 22

作者:CK Phua

1.png

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

面向未来的边缘智能,恩智浦最近发布了MCX产品组合,该平台可提供可扩展性能、并行性、安全性、高能效和丰富外设,针对广泛的物联网、边缘ML和工业应用场景进行了优化。MCX产品组合结合了恩智浦LPC和Kinetis MCU系列的DNA,为智能互联设备重新定义下一代通用MCU。

在MCX产品组合下,恩智浦首先推出的是MCX N高性能系列,专为安全、智能的边缘应用而设计。N系列中首先登场的是MCX N94x和MCX N54x MCU系列,具有高效的多核架构、内置EdgeLock®安全子系统和用于实时推理的专用内置神经处理单元(NPU)。MCX N94x系列适用于工业应用,具有更广泛的模拟和电机控制外设,而MCX N54x系列针对消费和物联网应用,集成了众多外设,包括带PHY的高速USB,SD和智能卡接口等。

立即浏览。恩智浦利用全新多核MCX N系列微控制器,寻求边缘处理的新突破。

150MHzMCU能带来什么?答案远超想象

使用低功耗的150MHz MCU实现多任务处理性能、高级神经网络和ML功能听起来似乎非常困难,但MCX N94x和MCX N54x并不是普通的MCU,而是多核设计和丰富外设的伟大结晶。

MCX N94x和MCX N54x基于高性能双核Arm® Cortex®-M33,运行频率高达150 MHz,片内集成高达2MB的闪存,可配置的带ECC检测的RAM、智能DMA、DSP协处理器、安全子系统和恩智浦设计的一体化NPU。开发人员可以使用这些内核和加速器的任意组合来完成具体任务,而无需提高MCU的时钟速度或增加功耗。

2.jpg

MCX N94x框图

片内多种加速器使MCX N系列MCU能够以低功耗预算高效地处理多个复杂任务,同时保证系统的安全性。多核设计通过智能、高效地将工作负载分配到模拟和数字外设,提高了系统性能并降低了功耗。因此,MCU的工作电流消耗小于45μA/MHz,如果启用实时时钟(RTC)和保持8KB SRAM,掉电模式下消耗的电流不到2.5μA,如果在启用RTC和8KB SRAM的深度掉电模式下,消耗的电流不到1μA。

双核架构将功能全面的Cortex-M33内核与M33从核相结合来管理控制功能,使开发人员能够并行运行应用程序,或根据需要关闭单个内核来降低总体功耗。例如,在物联网设备的安全无线(OTA)更新期间,主M33内核可以处理系统安全,而第二个从核执行控制功能。

随着MCX N系列发布,恩智浦自主研发的NPU初次亮相,以实现边缘的高性能和低功耗智能。与只使用CPU内核相比,内置NPU的ML吞吐量提高了30倍。

3.png

NPU的相对加速度

如此的ML性能表现在MCU领域堪称顶级,使得TinyML在资源和功率受限的边缘设备上展现超凡的算力。突破性能边界,畅想如下的应用可能,例如实现复杂的深度学习模型、为门禁控制添加人脸和语音识别功能、为家庭安全系统创建电池供电的玻璃破碎探测器、为电机控制预测维护开发振动传感器和设计配备生物传感器的智能可穿戴设备等等。

设计灵活安全

MCX N系列具有丰富的外设,就像开发人员的百宝箱。高精度混合信号模拟外设具备更强的自主性,可以减少CPU中断并节省电力。例如,ADC具备智能化设计,可以持续收集数据并在本地对存储的数据进行分配。MCU的两个16位ADC都可以用作两个单端输入ADC(有效地用作四个ADC)或用作单个差分输入ADC。

工业级通信外设包括以太网、CAN-FD、BLDC/PMSM电机控制支持、高速和全速USB以及内置传感器接口(MIPI-I3C、I2C、UART和SPI)。为了提高灵活性,恩智浦的低功耗Flexcomm接口允许十个串行外设(包括SPI、UART和I2C)任意组合。

MCX N系列MCU遵循恩智浦设计确保安全方案构建,集成了EdgeLock®安全子系统,可以安全启动不可变的信任根、实现硬件加速加密、主动和被动入侵检测以及电压和温度篡改检测。这种一流的安全架构为现场更新和在线传输提供支持,并防止远程原始设计制造商(ODM)过度生产。

MCUXpressoeIQ®软件快速入门

为了帮助简化和加速系统开发,MCX N系列MCU由恩智浦广受欢迎的MCUXpresso软件套件(包括用于简单设备配置和安全编程的工具)支持。开发人员可以选择使用功能全面的MCUXpresso IDE或IAR和Keil的IDE。恩智浦为驱动程序和中间件提供了大量示例并支持一系列RTOS选项,恩智浦的合作伙伴生态体系也提供了一系列兼容中间件,这样可以实现大量应用程序的快速开发。恩智浦的eIQ®ML软件开发环境还提供了易于使用的工具来训练和支持运行在内置NPU上的ML模型。

进一步探索MCX N系列

MCX N系列为具备低功耗、高性能要求的边缘人工智能提供了新的可能性。详细了解MCX N94x和MCX N54 MCU,或联系恩智浦全球销售人员

作者:

4.jpg

CK Phua

微控制器产品经理

CK于1993年加入飞利浦半导体公司,曾担任质量、应用工程、产品工程和技术营销等多个职位。继飞利浦之后,CK在2012年加入飞思卡尔,飞思卡尔合并后加入恩智浦。CK现任边缘处理业务部微控制器的产品经理。

围观 20
  • 集性能、集成、网络、信息安全和功能安全于一体,满足电动汽车牵引逆变器控制新需求

  • 在新一代区域汽车架构中,通过时间敏感网络(TSN)以太网支持边缘智能驱动应用

  • 搭载ASIL D解码软件和模拟外设集成,以降低系统成本

恩智浦半导体(NXP Semiconductors N.V.,纳斯达克股票代码:NXPI)宣布推出全新S32K39系列汽车微控制器(MCU),该系列MCU针对电动汽车(EV)控制应用进行了优化。新一代S32K39 MCU的高速、高分辨率控制可提高能效,在延长行驶里程的同时,提供更顺畅的电动汽车驾驶体验,满足未来电气化需求。S32K39 MCU的网络、信息安全和功能安全超越传统汽车MCU,可满足区域汽车E/E架构和软件定义汽车需求。借助新的MCU,恩智浦的电池管理系统(BMS)和电动汽车功能逆变器能够提供适用于下一代电动汽车的端到端解决方案。

微信图片_20221128133149.png

S32K39高性能MCU为实现牵引逆变器的智能、高精度控制而进行了优化,可将电动汽车电池的直流电转换为交流电,驱动现代化牵引电机。该系列MCU既支持传统的绝缘栅极双极性晶体管(IGBT),也支持新推出的碳化硅(SiC)和氮化镓(GaN)技术。S32K39高性能MCU通过双200 kHz控制环路提高能效,逆变器体积更小、更轻、更高效,行驶里程更长。该系列可控制六相电机,提高功率密度和容错性,保持长期高可靠性。此外,该系列搭载安全ASIL D软解码以及集成正弦波生成器与Σ-ΔADC,消除了对外部组件的需要,从而降低系统成本。与恩智浦S32E实时处理器结合使用时,S32K39还允许灵活地控制多达4个牵引逆变器,并且能够为采用该配置的4轮驱动电动汽车实施高级牵引功能。

S32K39系列采用多功能架构,因此除了适用于牵引逆变器控制,也适合许多其他电动汽车应用,包括电池管理(BMS)、车载充电(OBC)和DC/DC转换。此外,还支持硬件隔离、时间敏感网络和高级加密,已为支持软件定义汽车和区域架构做好充分准备。

恩智浦半导体汽车控制和电气化部门总监Allan Mcauslin表示:“S32K39 MCU集多种先进技术于一体,为汽车厂商提供巨大的灵活性和可扩展性,加速电动汽车开发及电气化新技术部署。凭借解决方案互补的全面产品组合,恩智浦引领行业发展趋势,为客户提供更好的电动汽车驾驶体验,同时加速推进电动汽车革命。”

关于S32K39

  • S32K系列中性能最出众的产品,搭载4个工作频率为320 MHzArm® Cortex®-M7内核,配置为一个锁步核和两个分立核

  • 高达6 MB闪存和800 KB SRAM

  • 两个电机控制协处理器和NanoEdge™高分辨率脉宽调制(PWM),实现更高性能和精度控制

  • 安全ASIL D软件分解器消除对外部组件的需要并降低成本

  • 集成的DSP提供灵活的数字滤波和机器学习(ML)算法

  • 多通道SARΣ-Δ A/D转换器、比较器和用于解码器激励的正弦波生成器

  • 6CAN FD接口、TSN以太网和多个高级可编程I/O

  • 通过使用公钥基础架构(PKI)和密钥管理,硬件安全引擎(HSE)实现可信启动、安全服务、安全无线远程升级(OTA

  • 还提供S32K37版本(不带双电机控制处理器)

  • 通过获得认证的ISO/SAE 21434网络安全和ISO 26262功能安全流程开发

  • 提供两种封装:176LPQFP-EP289MAPBGA

系统解决方案供货情况

目前,为主要客户提供工程样片、评估板和综合性软件支持与工具。S32K39 MCU可与恩智浦FS26安全系统基础芯片(SBC)和具备可调节动态栅极强度控制的先进高压隔离栅极驱动器GD3162结合使用,实现安全的逆变器控制系统。对于牵引逆变器开发,二者均支持最高级别的功能安全等级(ASIL D)。计划于2023年第4季度正式投入量产。

关于恩智浦电气化解决方案

恩智浦电气化解决方案采用可靠的开放式架构,可实现从电气化结点到云端的更安全的双向通信。我们的集成嵌入式技术让产品设计人员和服务提供商有信心构建满足最高功能安全和信息安全标准的系统;恩智浦还提供深度见解,助力提高产品整个生命周期的性能。恩智浦电气化解决方案的控制功能不局限于系统某个部分,而是覆盖整个生态系统,包括电池管理、高效电机驱动、快速充电及全车电气负载均衡。

有关更多信息,请访问nxp.com.cn/S32K39

关于恩智浦半导体

恩智浦半导体(纳斯达克代码:NXPI)致力于通过创新为人们更智慧、安全和可持续的生活保驾护航。作为全球领先的嵌入式应用安全连接解决方案提供商,恩智浦不断寻求汽车、工业物联网、移动设备和通信基础设施市场的突破。恩智浦拥有超过60年的专业技术及经验,在全球30多个国家设有业务机构,员工达31,000人,2021年全年营业收入110.6亿美元。更多信息,请访问https://www.nxp.com/

围观 22

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

面向未来的边缘智能,恩智浦最近发布了MCX产品组合,该平台可提供可扩展性能、并行性、安全性、高能效和丰富外设,针对广泛的物联网、边缘ML和工业应用场景进行了优化。MCX产品组合结合了恩智浦LPC和Kinetis MCU系列的DNA,为智能互联设备重新定义下一代通用MCU。 

在MCX产品组合下,恩智浦首先推出的是MCX N高性能系列,专为安全、智能的边缘应用而设计。N系列中首先登场的是MCX N94x和MCX N54x MCU系列,具有高效的多核架构、内置EdgeLock安全子系统和用于实时推理的专用内置神经处理单元(NPU)。MCX N94x系列适用于工业应用,具有更广泛的模拟和电机控制外设,而MCX N54x系列针对消费和物联网应用,集成了众多外设,包括带PHY的高速USB,SD和智能卡接口等。 

了解恩智浦如何利用全新多核MCX N系列微控制器,寻求边缘处理的新突破,点击这里>>

150MHz的MCU能带来什么?

使用低功耗的150MHz MCU实现多任务处理性能、高级神经网络和ML功能听起来似乎非常困难,但MCX N94x和MCX N54x并不是普通的MCU,而是多核设计和丰富外设的伟大结晶。 

MCX N94x和MCX N54x基于高性能双核Arm Cortex-M33,运行频率高达150MHz,片内集成高达2MB的闪存,可配置的带ECC检测的RAM、智能DMA、DSP协处理器、安全子系统和恩智浦设计的一体化NPU。开发人员可以使用这些内核和加速器的任意组合来完成具体任务,而无需提高MCU的时钟速度或增加功耗。 

2.jpg

MCX N94x框图 

片内多种加速器使MCX N系列MCU能够以低功耗预算高效地处理多个复杂任务,同时保证系统的安全性。多核设计通过智能、高效地将工作负载分配到模拟和数字外设,提高了系统性能并降低了功耗。因此,MCU的工作电流消耗小于45μA/MHz,如果启用实时时钟(RTC)和保持8KB SRAM,掉电模式下消耗的电流不到2.5μA,如果在启用RTC和8KB SRAM的深度掉电模式下,消耗的电流不到1μA。 

双核架构将功能全面的Cortex-M33内核与M33从核相结合来管理控制功能,使开发人员能够并行运行应用程序,或根据需要关闭单个内核来降低总体功耗。例如,在物联网设备的安全无线(OTA)更新期间,主M33内核可以处理系统安全,而第二个从核执行控制功能。 

随着MCX N系列发布,恩智浦自主研发的NPU初次亮相,以实现边缘的高性能和低功耗智能。与只使用CPU内核相比,内置NPU的ML吞吐量提高了30倍。 

3.png

NPU的相对加速度

如此的ML性能表现在MCU领域堪称顶级,使得TinyML在资源和功率受限的边缘设备上展现超凡的算力。突破性能边界,畅想如下的应用可能,例如实现复杂的深度学习模型、为门禁控制添加人脸和语音识别功能、为家庭安全系统创建电池供电的玻璃破碎探测器、为电机控制预测维护开发振动传感器和设计配备生物传感器的智能可穿戴设备等等。 

设计灵活安全

MCX N系列具有丰富的外设,就像开发人员的百宝箱。高精度混合信号模拟外设具备更强的自主性,可以减少CPU中断并节省电力。例如,ADC具备智能化设计,可以持续收集数据并在本地对存储的数据进行分配。MCU的两个16位ADC都可以用作两个单端输入ADC(有效地用作四个ADC)或用作单个差分输入ADC。 

工业级通信外设包括以太网、CAN-FD、BLDC/PMSM电机控制支持、高速和全速USB以及内置传感器接口(MIPI-I3C、I2C、UART和SPI)。为了提高灵活性,恩智浦的低功耗Flexcomm接口允许十个串行外设(包括SPI、UART和I2C)任意组合。 

MCX N系列MCU遵循恩智浦设计确保安全方案构建,集成了EdgeLock安全子系统,可以安全启动不可变的信任根、实现硬件加速加密、主动和被动入侵检测以及电压和温度篡改检测。这种一流的安全架构为现场更新和在线传输提供支持,并防止远程原始设计制造商(ODM)过度生产。 

MCUXpresso和eIQ软件快速入门

为了帮助简化和加速系统开发,MCX N系列MCU由恩智浦广受欢迎的MCUXpresso软件套件(包括用于简单设备配置和安全编程的工具)支持。开发人员可以选择使用功能全面的MCUXpresso IDE或IAR和Keil的IDE。恩智浦为驱动程序和中间件提供了大量示例并支持一系列RTOS选项,恩智浦的合作伙伴生态体系也提供了一系列兼容中间件,这样可以实现大量应用程序的快速开发。

恩智浦的eIQ ML软件开发环境还提供了易于使用的工具来训练和支持运行在内置NPU上的ML模型。 

进一步探索MCX N系列

MCX N系列为具备低功耗、高性能要求的边缘人工智能提供了新的可能性。

了解 MCX N94x和MCX N54 MCU更多详情,请联系恩智浦全球销售人员,也可点击这里>>

来源:NXP客栈

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

围观 56

恩智浦半导体宣布推出MCX微控制器产品组合N系列中的首批产品:MCX N94x和MCX N54x。MCX N系列微控制器专为简化安全智能边缘应用(包括物联网和工业应用)打造,首次集成了恩智浦专有神经处理单元 (NPU),并集成了EdgeLock安全子系统。MCX N系列器件采用多核设计,可智能、高效地将工作复杂分配到模拟和数字外设,提升系统性能并降低功耗。

1.jpg

如今的开发者需要微控制器能够具备更高的处理能力,才能将单纯的边缘数据转换为边缘智能,同时还要尽可能地控制功耗,以保持高能效。MCX N94x和MCX N54x系列微控制器支持广泛的模拟和数字外设,为工程师提供打造创新设计所需的灵活性和高性能,同时维持高性能边缘处理所必需的低功耗。

“开发者不断创造新的设备,激发边缘潜力,进一步助力智能家居、智能工厂和智慧城市领域实现智能化和自动化。我们需要先进的MCU,提高效率,简化边缘智能,并安全地完成所有工作。面向未来的智能边缘,我们推出了MCX N系列,助力未来的物联网和工业应用在功率和性能之间实现平衡。” 

——Rafael Sotomayor

恩智浦边缘执行副总裁兼连接与安全和边缘处理事业部总经理

MCX N系列微控制器更多详情

MCX N系列双核系统搭载功能齐全的Arm Cortex-M33主核和精简化的Cortex-M33从核来管理控制功能,让开发者可以并行运行多个应用,必要时还可以通过关闭单个内核来降低功耗。比如,在无线 (OTA) 通信等安全物联网应用中,主内核负责维护系统安全,而从核负责执行控制功能。 

MCX N94x和MCX N54x采用高性能双核Cortex-M33,运行频率高达150MHz,提供2MB闪存以及可配置的带ECC的RAM,和用于音频和语音处理的DSP协处理器,并集成了NPU。与单独的CPU内核相比,集成的NPU可提供高达30倍的机器学习运算加速,同时多个协处理器和加速器可缩短唤醒时间并降低整体功耗。除此之外,恩智浦的eIQ机器学习软件开发环境提供了多个易于使用的工具,以训练和支持使用集成式NPU的机器学习模型。 

MCX N系列器件提供丰富的外设。MCX N94x带有各类先进模拟和电机控制外设,而MCX N54x也包含高速USB(具备PHY),SD或智能卡接口等适用于物联网和消费者应用的外设。 

该系列新型器件遵循恩智浦设计确保安全的思路构建,能够提供具有不可变信任根和硬件加速加密的安全启动,并且内置EdgeLock安全子系统。此架构支持现场更新和在线交易,并能防止远程原始设计制造商 (ODM) 出现过度生产。 

利用软件和工具简化开发

MCX N系列器件受到广泛采用的MCUXpresso开发工具和软件套件支持,可优化、简化和加速嵌入式系统的开发工作。

MCUXpresso套件包括用于简化器件配置和安全编程的工具。开发者可以选择使用功能齐全的MCUXpresso IDE,也可以使用IAR和Keil的IDE。

恩智浦为驱动和中间件提供了广泛的示例并支持一系列RTOS选择,另外还有恩智浦合作伙伴生态系统带来的大量兼容中间件,让开发者能够快速开发各式各样的终端应用。 

供货情况

来源:NXP客栈

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

围观 31

本人很久以前写过一篇文章 《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)。

1.png

如果你仔细看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""

2.png

1.2 Keil MDK下

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

3.png

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

4.png

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

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

5.png

我们知道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"

6.png

来源:恩智浦MCU加油站

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

围观 126

众所周知,一款优秀的产品,不仅要有很高的性能,很好的稳定性,而且还要具备对用户非常友好和极具吸引力的图形交互界面。

然而,运行一个非常酷炫且极具吸引力的图形用户界面,就要求有一个高主频,高性能,存储资源丰富的MCU作为支撑。 

恩智浦拥有众多高性能,低功耗,大容量存储资源的MCU/MPU, 在这样的MCU/MPU上,流畅地运行图形元素丰富,酷炫且富于吸引力的图形用户界面完全没有压力。

但是,在实际的客户支持过程中,我发现有一些客户基于成本的考虑,会选择主频相对低一些,存储资源相对少一些的MCU。与此同时,他们仍然希望给自己的产品赋予一个精美的图形界面。

 真实案例——电动车屏幕

因此,本文通过一个运行在LPC55S06上的,基于GUI Guider和LVGL的图形界面设计项目——电动车(简称EBike)为例,说明如何在资源有限的MCU上进行图形应用设计。

先睹为快,先给大家分享电动车的界面效果。通过向右滑屏可以切换到下一个屏幕,向左滑屏可以切换到前一个屏幕,向上滑屏可以返回至第一个屏幕,下面是演示视频:

查看视频.jpg

图片与字体的存储

在设计中, 电动车的GUI使用了大小为1.18MB的26个图片和大小为35KB的2种字体,共计约为1.22MB。

但事实上,LPC55S06的片上Flash容量为256KB,其中12KB为系统保留,可以为用户使用的Flash容量只有244KB,不可能将全部图片和字体存放到片上Flash中。

因此,为了能够容纳这些图片和字体,可以考虑外扩Flash。同时,为了兼顾显示性能,可以考虑将图片存放到外部串行Flash中,而将字体存放到片上Flash中。

归纳一下,在资源有限的MCU上进行图形界面开发,首先需要考虑的因素就是如何存储图片和字体。为了提高显示性能,可以把图片和字体尽可能放到片上Flash中存储。但是,随着开发的推进,用户会不断添加非图形界面业务逻辑。这时,如果遇到片上Flash存储空间不够的情况,可以将原本存放到片上Flash中的图片和字体放到外部Flash中,从而节省片上Flash存储空间给非图形界面业务逻辑使用。

存储区域的划分与分配

那么,这里存在一个关键问题,如何为图片和字体分配存储空间呢,依据什么原则呢?换句话说,哪些图片和字体存放到外部Flash,哪些图片和字体存放到片上Flash。

第一点,就是确保片上Flash可以容纳全部用户应用逻辑。

第二点,在满足第一点的情况下,将需要频繁刷新的图片保存到片上Flash。例如,视频所示界面中仪表盘的表针扫过的区域使用的图片,随着表针的转动,这些图片会不断地从外部Flash进行读取并被显示在屏幕上。

常见优化手段

除了将消耗片上Flash资源的大户放到外部Flash上,为了进一步减少用户应用对存储资源的消耗,一些优化手段也是必要的。

常用的优化手段包括如下几点:

  • 将经常需要调用的公共代码段封装成函数 

  • 调整编译优化等级。使用不同的编译优化等级编译生成的可执行文件大小是不同的,如果所选的编译器具有优化代码大小的编译优化选项,则可以通过使用该编译优化选项压缩可执行文件的大小,从而减少对Flash和RAM存储资源的占用。不同IDE中优化代码大小的编译选项如下所示。

1.png

图1 MCUXpresso IDE中的代码大小编译优化选项

2.png

图2 Keil uVision IDE中的代码大小编译优化选项

3.png

图3 IAR Embedded Workbench IDE中的代码大小优化选项

  • 通过LVGL的配置文件lv_conf.h跳过设计中没有使用的模块的编译。例如,在我们的设计中没有用到控件,如SWICH, TABLE, TABVIEW和TILEVIEW, 就可以将相应控件的开关宏定义为0,这样没有使用的控件对应的C文件就不会编译到最终的可执行文件中,从而减少代码的大小。

4.png

图4 裁剪LVGL功能

选择合理的屏幕加载策略

了解LVGL的小伙伴都清楚,GUI上的每一个图形元素,如按钮、图片、标签、表格等,都是作为一个对象存在的,都是需要消耗一定的RAM资源。

如果我们的GUI设计包含多个屏幕,每个屏幕都包含大量的图形元素,如果一次性的创建所有的图形元素,很可能有限的RAM资源不足以容纳这些图形元素。因此,合理的选择屏幕加载策略很有必要。

基于LVGL的GUI开发工具采用不同的屏幕加载策略。目前,屏幕加载策略有两种:

第一种是以LVGL官方推出的SquareLine Studio为代表的静态加载策略,即一次性地把所有屏幕上的图形元素全部创建。这可以从其生成的代码工程看到。

以SquareLine Studio的POS机界面示例为例,其UI初始化函数如下图所示。我们可以看到其5个屏幕一次性创建,那么就意味着这种静态屏幕加载策略消耗更多的RAM资源。

5.png

图5 SquareLine Studio的UI初始化

第二种是以NXP官方推出的GUI Guider为代表的动态加载策略,即只加载在系统启动后显示的屏幕,后面如果需要显示哪一个屏幕再动态加载。

下图所示是GUI Guider的官方示例ScreenTransition。这个示例总共有两个屏幕,即screen1与screen2。函数setup_ui是UI初始化函数。

可以看到,在UI初始化函数setup_ui中只是静态加载了屏幕screen1,没有加载screen2。只有当screen1的Next Screen按钮按下时,在事件回调函数screen_btn1_event_handler中才会调用setup_scr_screen2动态加载screen2。

6.png

图6 ScreenTransition示例的第一个屏幕

7.png

图7 ScreenTransition示例的第二个屏幕

8.png

图8 GUI Guider的UI初始化

9.png

图9 Next Screen按钮的事件回调函数

由此可见,NXP的GUI Guider的动态屏幕加载策略,充分考虑了在资源有限的微控制器上从事GUI开发时,遇到的存储资源利用效率问题。

当然,如果您所选择的MCU或者MPU的存储资源丰富,可以采用第一种策略,那样的话,可以能在一定程度上提高显示性能。

总结

本篇文章以一个GUI示例——电动车为例,重点关注如何在资源有限的微控制器上进行GUI开发,给出了图片和字体的存储策略,以及若干存储资源优化方法。

有关电动车的技术细节,可以参考AN13730: How to Develop LVGL GUI Demo on Memory-constrained MCU with GUI Guider.

来源:恩智浦MCU加油站

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

围观 419

关于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需要根据存储器实际情况来设置。

“理解i.MX

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

“理解i.MX

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

“理解i.MX

看到这里,似乎已经把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)。

“理解i.MX

二、常见行列混合地址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] 是低位列地址。

“理解i.MX

“理解i.MX

再来看 \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

“理解i.MX

“理解i.MX

对于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),
};

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

围观 60

页面

订阅 RSS - 恩智浦