STM32

STM32是STMicroelectronics(意法半导体)推出的一系列基于ARM Cortex-M内核的32位微控制器(MCU)产品。这些微控制器提供了广泛的产品系列,覆盖了多种不同的性能和功能需求,适用于各种应用领域,包括工业控制、汽车电子、消费类电子、医疗设备等。

STM32系列微控制器以其高性能、低功耗、丰富的外设接口和灵活的开发工具而闻名。它们通常具有丰富的存储器、多种通信接口(如UART、SPI、I2C、CAN等)、模拟数字转换器(ADC)、定时器、PWM输出等功能,以满足不同应用场景下的需求。

STM32微控制器通常使用标准的ARM Cortex-M内核,包括Cortex-M0、M0+、M3、M4和M7等,这些内核具有不同的性能和功耗特性,可根据具体应用的需求进行选择。此外,STM32系列还提供了多种封装和引脚配置,以满足不同尺寸和集成度的要求。

STMicroelectronics为STM32系列提供了丰富的开发工具和支持资源,包括基于ARM开发环境的集成开发环境(IDE)、调试器、评估板和参考设计等。这些工具和资源有助于开发人员快速开发和部署他们的应用,并提供了全面的技术支持和文档资料,帮助用户充分发挥STM32微控制器的性能和功能优势。

全球光伏行业能够跨越式发展离不开储能技术的快速崛起。储能技术在发电端、电网侧、负荷端都有需求,光储融合,全面提升了光伏发电的渗透率。

为什么这么说呢?因为储能技术能够有效解决光伏发电的间歇性和波动性问题,以及与用电高峰的时差问题,能够让普惠光伏进入千家万户。

1.png

光伏储能系统是具有多种应用的复杂系统,STM32可用于多个子系统。如光伏板上的优化器、RSD(快速关断)、拉弧检测、DC-DC/双向DC-AC功率转换、通信监看的人机交互界面等等。

实现“比特管理瓦特”,数字电源不可少

光伏储能,技术同源,是因为光伏发电和储能技术都需要一个关键技术,就是电能转换。

我们都知道,电能转换有四种形式:AC-DC、AC-AC、DC-AC和DC-DC。在光伏储能系统中,会用到AC-DC、DC-AC和DC-DC三种电能转换形式。

因此,逆变器可谓是光伏储能系统的心脏所在。

《STM32在光储系统中的应用》视频将分上、下两集向大家解读STM32的应用解决方案。

光储逆变器的本质是一种电源产品,因其复杂程度,通常采用数字电源实现。而这种电源要求更高的系统效率,来满足最严格的能源要求;更高的功率密度与开关频率,以及更快速的控制回路;能管理复杂拓扑并具备设计灵活性。

所谓的数字电源实际上就是一种采用数字信号来控制开关电源的开关状态和频率,并通过微处理器(MCU)等对电源输出进行控制和监测的功率转换解决方案。

在光储系统中,实现“比特管理瓦特”的过程,缺不了数字电源。

数字电源的优点很多,比如软件可编程、可实现更高级的控制算法、更复杂的拓扑结构、集成度高、一致性好,具有可扩展性和可重用性。在复杂的多系统应用中,优势非常突出。

STM32提供平台化解决方案STM32 D-Power产品组合,融合DSP和模拟信号处理能力,推动能源转换数字化。

2.png

其中,新品STM32G4和STM32H7系列,内嵌全功能高精度定时器(HRTimer),精度高达 184皮秒;可配置高灵活度 PWM 波形;具有丰富的事件管理和极速的故障保护功能。

STM32为数字电源应用打造了完整的产品生态,包含多种硬件开发板,免费软件开发工具eDesignSuite,以及针对不同电路拓扑配置高精度定时器的技术文档等。

ST可提供全面的数字电源模块产品

STM32在光伏储能系统的方案成熟,经市场头部企业验证。

3.png

典型数字电源系统的关键构建模块主要包括两个部分:控制单元和功率级。除了MCU和MPU ,ST 还可以提供多种功率器件,尤其是SiC二极管、SiC MOSFET、以及不同集成度的GaN解决方案。

STM32关注光伏储能发展,持续的研发投入将带来更丰富的解决方案,进一步提升光伏转换效率,为光伏市场发展提供源动力。

相关阅读:

日光倾城,低碳未来 | STM32在光伏储能中的应用(上)

来源:STM32

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

围观 12

学习STM32单片机的时候,总是能遇到“堆栈”这个概念。分享本文,希望对你理解堆栈有帮助。

对于了解一点汇编编程的人,就可以知道,堆栈是内存中一段连续的存储区域,用来保存一些临时数据。堆栈操作由PUSH、POP两条指令来完成。而程序内存可以分为几个区:

  • 栈区(stack)

  • 堆区(Heap)

  • 全局区(static)

  • 文字常亮区程序代码区

程序编译之后,全局变量,静态变量已经分配好内存空间,在函数运行时,程序需要为局部变量分配栈空间,当中断来时,也需要将函数指针入栈,保护现场,以便于中断处理完之后再回到之前执行的函数。
栈是从高到低分配,堆是从低到高分配。

普通单片机与STM32单片机中堆栈的区别

普通单片机启动时,不需要用bootloader将代码从ROM搬移到RAM。

但是STM32单片机需要。

这里我们可以先看看单片机程序执行的过程,单片机执行分三个步骤:

  • 取指令

  • 分析指令

  • 执行指令

根据PC的值从程序存储器读出指令,送到指令寄存器。然后分析执行执行。这样单片机就从内部程序存储器去代码指令,从RAM存取相关数据。

RAM取数的速度是远高于ROM的,但是普通单片机因为本身运行频率不高,所以从ROM取指令慢并不影响。

而STM32的CPU运行的频率高,远大于从ROM读写的速度。所以需要用bootloader将代码从ROM搬移到RAM。

使用栈就象我们去饭馆里吃饭,只管点菜(发出申请)、付钱、和吃(使用),吃饱了就走,不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作,他的好处是快捷,但是自由度小。使用堆就象是自己动手做喜欢吃的菜肴,比较麻烦,但是比较符合自己的口味,而且自由度大。

其实堆栈就是单片机中的一些存储单元,这些存储单元被指定保存一些特殊信息,比如地址(保护断点)和数据(保护现场)。

如果非要给他加几个特点的话那就是:

  • 这些存储单元中的内容都是程序执行过程中被中断打断时,事故现场的一些相关参数。如果不保存这些参数,单片机执行完中断函数后就无法回到主程序继续执行了。

  • 这些存储单元的地址被记在了一个叫做堆栈指针(SP)的地方。

结合STM32的开发讲述堆栈

从上面的描述可以看得出来,在代码中是如何占用堆和栈的。可能很多人还是无法理解,这里再结合STM32的开发过程中与堆栈相关的内容来进行讲述。

如何设置STM32的堆栈大小?

在基于MDK的启动文件开始,有一段汇编代码是分配堆栈大小的。

1.png

这里重点知道堆栈数值大小就行。还有一段AREA(区域),表示分配一段堆栈数据段。数值大小可以自己修改,也可以使用STM32CubeMX数值大小配置,如下图所示。

2.png

STM32F1默认设置值0x400,也就是1K大小。

Stack_Size EQU 0x400

函数体内局部变量:

void Fun(void){ char i; int Tmp[256]; //...}

局部变量总共占用了256*4 + 1字节的栈空间。所以,在函数内有较多局部变量时,就需要注意是否超过我们配置的堆栈大小。

函数参数:

void HAL_GPIO_Init(GPIO_TypeDef *GPIOx, GPIO_InitTypeDef *GPIO_Init)

这里要强调一点:传递指针只占4字节,如果传递的是结构体,就会占用结构大小空间。提示:在函数嵌套,递归时,系统仍会占用栈空间。

堆(Heap)的默认设置0x200(512)字节。

Heap_Size EQU 0x200

大部分人应该很少使用malloc来分配堆空间。虽然堆上的数据只要程序员不释放空间就可以一直访问,但是,如果忘记了释放堆内存,那么将会造成内存泄漏,甚至致命的潜在错误。

MDK中RAM占用大小分析

经常在线调试的人,可能会分析一些底层的内容。这里结合MDK-ARM来分析一下RAM占用大小的问题。在MDK编译之后,会有一段RAM大小信息:

3.png

这里4+6=1640,转换成16进制就是0x668,在进行在调试时,会出现:

4.png

这个MSP就是主堆栈指针,一般我们复位之后指向的位置,复位指向的其实是栈顶:

5.png

而MSP指向地址0x20000668是0x20000000偏移0x668而得来。具体哪些地方占用了RAM,可以参看map文件中【Image Symbol Table】处的内容:

6.png

来源:嵌入式Linux

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

围观 15

新款STM32U5片上集成矢量图形加速器及大容量SRAM存储器

意法半导体推出了集成新的专用图形加速器的STM32*微控制器(MCU),让成本敏感的小型产品也能为用户带来更好的图形体验。超低功耗MCU STM32U5F9/G9STM32U5F7/G7集成3MB片上动态存储器(SRAM),可以为图形显示屏提供多个帧缓存区,以节省外部存储芯片。新产品还集成了意法半导体的NeoChromVG图形处理器(GPU),能够实现的图形效果可与更昂贵的高端微处理器相媲美。

1.jpg

新系列STM32U5内置 NeoChromVG图形处理器,是STM32首批支持硬件加速矢量运算的MCU,能够渲染 SVG图像和矢量字体。内嵌的专用 GPU 还可以实现图像旋转、Alpha透明度混合和精确视角的纹理映射等高端图效。此外,新款MCU 还有处理 MJPEG 视频的 JPEG 编解码器。这些功能让产品开发人员可以在智能家电、智能家居控制器、电动自行车和工业终端设备中使用动态图标、支持多种不同尺寸的字体、可缩放地图、视频播放等技术,为消费者带来更炫酷、更有趣、更直观好用的新一代便携式产品。

在片上集成先进的图形处理功能和大容量 RAM 存储器后,设计人员无需外部存储器就可以开发高性能的图形子系统,从而节省了 PCB 空间,无需片外高速信号传输。除了 3MB SRAM存储器外,片上还集成了 4MB 闪存,为代码和数据提供了充足的非易失性存储空间。

新款MCU在低成本100引脚LQFP封装内集成所有电路,可以实现简单的4层PCB设计,避免信号布线和电磁兼容性 (EMC)引起的常见问题。在为这些 MCU专门开发的STM32U5G9J-DK2图形开发套件中,意法半导体展示了这种设计思路,开发人员可以将其用作硬件参考设计,加快产品上市。

ST 授权合作伙伴 Riverdi 已经使用 STM32U5F9/G9 MCU 开发出了具有高级图形功能的新产品。Riverdi 的联席首席执行官 Kamil Kozłowski 表示: “ 最新的 STM32 MCU是兼具优异图显功能与成本灵活性的单芯片方案,使我们能够以更具吸引力的价格推出 5 英寸显示模块,为终端产品厂商提供专业的整体显示方案,帮助他们为自己的产品设计定制化用户界面。我们基于 STM32U5F9/G9 的新型嵌入式显示器解决方案完全集成在 ST 的 TouchGFX GUI 设计框架内,客户打开显示器包装后,就可以立即着手开发自己的 UI 。”

STM32U5F9/G9STM32U5F7/G7属于STM32U5 超低功耗产品线,采用先进高能效的 Arm® Cortex®-M33处理器内核,在 160MHz 频率运行时处理速度达到 240 DMIPS,ULPMark-CoreProfile (CP)测试成绩为464分。该系列MCU具有200nA 待机模式、支持部分RAM内容保留和快速唤醒功能的多种低功耗模式,运行模式下功耗仅为 16μA/MHz ,在功耗优化和提升性能方面具有更大的灵活性。

开发人员还可以利用经过市场检验的STM32 外设和 IoT 硬件安全功能,以及包括软件工具、中间件、库和代码示例在内的 STM23Cube 生态系统。

STM32U5F9/G9 和 STM32U5F7/G7 现已上市。

关于意法半导体

意法半导体拥有5万名半导体技术的创造者和创新者,掌握半导体供应链和先进的制造设备。作为一家半导体垂直整合制造商(IDM),意法半导体与二十多万家客户、成千上万名合作伙伴一起研发产品和解决方案,共同构建生态系统,帮助他们更好地应对各种挑战和新机遇,满足世界对可持续发展的更高需求。意法半导体的技术让人们的出行更智能,让电源和能源管理更高效,让云连接的自主化设备应用更广泛。意法半导体承诺将于2027年实现碳中和(在范围1和2内完全实现碳中和,在范围3内部分实现碳中和)。详情请浏览意法半导体公司网站:www.st.com

围观 31
光伏发电技术凭借其绿色、环保的优势,已成为绿色经济引擎,海内外市场呈现跃进式发展态势。随着投资成本不断下降、发电效率逐年提升,全球光伏平价大时代已经来临。

但是光伏发电技术发出的电力不稳定,具有间歇性,且与用电高峰存在时差等问题,因此电力系统引入储能技术提升电网的灵活性,平滑电力输出,起到调峰调频的作用,光伏储能技术一体化成为新的发展趋势。在光储技术一体化系统中,STM32提供多种交钥匙解决方案。

1.jpg

太阳光照射在光伏板上,通过光伏效应将光能转换为直流电能,这时需要电弧检测与阻断技术(AFCI,Arc-Fault Circuit-Interrupter)来保证光伏发电的安全。STM32G4及STM32H7系列,结合边缘AI算法,可实现精准的拉弧识别。

发出来的电能需要进行远距离传输,在配电上网前,要将直流电逆变为交流电,这就需要用到电能逆变系统(PCS,Power Conversion System),STM32可提供平台化解决方案。

因电网调峰调频的需要,暂时不能上网的电能,需要储存起来作为备用电源,这就用到储能系统(ESS,Energy Storge System),STM32同样可提供经过市场验证的方案。

我们还需要人机交互系统(HMI,Human Machine Interface)对光伏系统的工作情况进行实时监看。根据通信监控模块的不同复杂程度,可选用STM32F4、STM32H7、STM32H5等系列;如果需要更高的CPU性能、图形性能,或者运行Linux系统,STM32MP1系列是理想的选择。除了这些子系统,STM32还可用于RSD(快速关断)、MPPT(最大功率点跟踪)等系统中。

基于STM32+AI的智能电弧检测与阻断方案(AFCI)

光伏发电在全球迅猛发展的同时,安全问题备受关注,其中最突出的是直流拉弧引起的电气火灾。直流拉弧是电路断点处击穿空气产生的持续火花。在光伏系统中,持续的电弧会使温度升高,可能引发火灾。

拉弧故障产生的原因很多,接点松脱、接触不良、线缆老化、极端故障天气、环境恶劣等等,且很难检测。电弧检测及阻断技术被寄予厚望,它能在电弧产生时快速识别并切断,避免电弧高温导致火灾,保证光伏系统的安全。AFCI系统在设计时存在很多难点。如逆变器开关电源噪声、多变的天气,以及快速关断设备的载波通信频率与光伏系统中的PLC通信频率重合造成的干扰等等。

STM32推出了交钥匙的解决方案,可以帮助客户快速实现电弧检测产品开发。基于STM32+AI的AFCI方案,通过在信号采集部分的逆变器输入端的互感器,将信号输入到AFCI检测板。当神经网络模型检测到故障后,通过通信接口告诉关断设备切断故障,并向主控单元报告实时拉弧状况。

STM32G4和STM32H7两个系列都具有快速、高精度ADC,均能满足拉弧检测要求,只是在检测速度和精度上有差异。

  • STM32G474是主频170MHz的Cortex-M4内核MCU,有5个4MSPS 的12位 ADC;

  • STM32H7A3是主频280MHz的Cortex-M7内核MCU,有2个3.6MSPS 的16位 ADC;

  • STM32H723是主频550MHz的Cortex-M7内核MCU,有2个3.6MSPS 的16位 ADC 和1个5MSPS 的12位 ADC;

  • STM32H743是主频480MHz的Cortex-M7内核MCU,有3个3.6MSPS的16位ADC。

为方便客户快速上手,我们还提供拉弧检测的硬件评估板。

电弧检测及阻断技术守护光伏发电的安全,STM32提供坚实可靠的助力。

欲了解更多基于STM32+AI的智能电弧检测与阻断方案(AFCI),请访问以下网址:https://stm32ai.st.com/,或联系ST官方代理商。

来源:STM32

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

围观 17

在高速发展的物联网时代,创新与协作成为引领技术前进的关键所在。意法半导体与深圳创新微技术有限公司(简称为“创新微MinewSemi”)深入合作,基于STM32的BlueNRG及STM32系列芯片,结合创新微MinewSemi在物联网连接模块领域的研发技术和生产实力,共创适用于智能家居、智能制造、智慧城市等不同应用场景的多款低功耗模块,为物联网通讯及智能连接赋能。

本次STM32与创新微MinewSemi合作开发了三款低功耗模块,即低功耗蓝牙模块MS23SF1、MS53SF1和低功耗LoRa模块 MS53SF2,可广泛应用于物联网设备、可穿戴技术、智能家居、智慧农业等领域,解决客户在低功耗模块智能连接方面的应用痛点,为行业客户带来全新体验。

1.png

后续STM32与创新微MinewSemi还将持续深耕基于低功耗模块的物联网连接多场景应用,不断为市场带来更多前瞻性解决方案和应用技术,引领中国智能连接的生态发展。

强强联合,共创低功耗模块

低功耗蓝牙模块——MS53SF1

MS53SF1是基于高度灵活、超低功耗的BlueNRG-355MC SoC的BLE 5.2 LNA模块。支持主从同步连接,支持多主多从工作模式,能被(采集器、手持设备)主机连接的同时,还可与多个从机(外置负荷开关、各类外置传感器)建立并发数据连接。

模块特点:

  • 搭载BlueNRG-355MC芯片

  • 小尺寸(20x12x2mm)

  • 低功耗蓝牙5.2 LNA模块

  • 支持主从同步连接

  • 支持多主多从工作模式

  • 125kbps速率下透传距离可达500米

  • 支持ANT、BLE、BLE MESH、ZIGBEE和 THREAD等协议

2.png

STM32官网产品模块:>>点击查看

低功耗蓝牙模块——MS53SF2

MS53SF2基于BlueNRG-332AC的高度灵活、超低功耗、高性价比的无线BLE 5.3模块。支持高速率、长距离、广播扩展、信道选择算法、测向(AoA/AoD)等。在125kbps的数据速率,它在开放空间范围内透传距离最远可达500米。

模块特点:

  • 搭载BlueNRG-332A芯片
  • 小尺寸(20x12x2mm)
  • 低功耗蓝牙5.3模块
  • 可外置增加PA及LNA
  • 超远传输距离透传距离可达500米
  • 支持信道选择算法
  • 支持可选外置天线

3.png

STM32官网产品模块:>>点击查看

低功耗LoRa模块——MS23SF1

MS23SF1是一款LoRaWAN®收发模块。其选用STM32的LoRaWAN无线半双工SoC芯片STM32WLE5CC,支持全球ISM频率,具有低功耗、超远距离、易用小巧等特点,同时还可支持多接口(SPI、UART、I2C、DAC、ADC)。

模块特点:

  • 搭载STM32WLE5CCU6芯片
  • 小尺寸(20.72x19.13x3.2mm)
  • 内置主频48MHZ Arm Cortex-M4
  • 可编程比特率,内部RAM64KB,Flash256KB
  • 通信距离可达5KM
  • 多IO口,支持GPIO24
  • 最高功率可达到+20.5dBm,灵敏度低至-146dBm

4.png

STM32官网产品模块:>>点击查看

合作共赢、技术创新是在快节奏发展中取得成功的关键。STM32和创新微MinewSemi的通力合作,结合双方技术优势、生产实力、体系化产品认证等能力,互利共赢、推陈出新,开发推出更具创新性产品和解决方案,不断推动“万物互联”的生态发展,为中国智能连接生态的高质量赋能。

关于创新微MinewSemi

创新微MinewSemi是云里物里全资子公司,是一站式物联网无线连接模块供应商,专注于物联网连接模块领域的研发创新和生产,包括BLE、GNSS、Wi-Fi、LoRa、UWB、毫米波雷达等全面的物联网模块产品,广泛应用于智能家居、智能制造、智慧城市、医疗健康等十余个领域,以射频、通信、组网、嵌入式等科技赋能全球80多个国家和地区。

来源:STM32

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

围观 21

一、引言

在之前的 STM32MCU TrustZone 开发调试技巧的系列文章中,我们已经介绍了 ARM CM33 内核 Trust Zone 特性,STM32MCU 的系统级 TrustZone 架构设计,TrustZone 环境下使用外设的注意事项,以及 HardFault 的处理和调试等内容。我们知道在某些较为复杂的应用中,往往还会用到 RTOS,在这个系列的最后一篇,我们将主要讨论 STM32MCU 应用程序开发中,在 TrustZone 环境下使用 RTOS 时的情况以及相关软件开发的一些注意事项,供开发者参考。

二、TrustZone 环境+RTOS 的软件架构

通常情况下,在 TrustZone 环境中,Secure 安全侧的代码主要负责处理一些关键数据的操作和关键外设的管理和控制,而更多的业务逻辑相关的应用程序则会运行在 TrustZone 的Non-Secure 非安全侧。软件的开发模式也会由原来的单一应用程序工程变为安全加非安全两个工程的联合开发。系统复位后 CPU 总是从安全工程的 reset handler 开始运行,安全代码完成初始化以及系统的安全配置之后,调用非安全代码的 reset handler 切换到非安全状态,继而开始运行非安全侧代码,非安全代码执行过程中可能会调用安全侧代码提供的一些API 函数,这个过程类似图 1 所示。

1.png

2.1. TrustZone 环境中 NS 代码不使用 RTOS 的情况

在逻辑相对简单的应用中,非安全侧代码不使用 RTOS,应用程序代码完成初始化之后会进入一个主循环,顺序执行各种操作,其间可能被中断打断。此时安全和非安全工程之间的关系也比较简单,基本上涉及的是直接的函数调用,可能是从非安全侧调用安全侧的API,或者从安全代码调用非安全侧注册的回调函数,类似图 2 所示。

2.png

2.2. TrustZone 环境中在 NS 代码使用 RTOS 的情况

在处理逻辑更复杂的应用中,应用程序可能需要用到 RTOS 来同时执行多个任务,此时RTOS 的功能例如多线程管理、mutex、semaphore、消息队列等也会在非安全侧使用,非安全侧既有 RTOS 的内核,也有上层执行业务逻辑的线程,应用线程中可能调用安全侧提供的 API 函数,类似图 3 所示。

3.png


这时候安全侧依旧是没有 RTOS 的环境,和裸跑时候一样不运行任何的调度器(scheduler),安全侧本身没有多线程的概念,也没有一直运行的任务,安全侧代码只是被动地提供一些 API 函数,供非安全侧软件来调用。这个过程看起来似乎与不使用 RTOS 的时候一样,但是一旦非安全侧有了 RTOS 和多线程的参与,而且线程又需要调用安全侧的 API,实际情况相比非安全侧裸跑就变得复杂了。接下来,我们来看几种可能的情况:

  • Case1:应用线程 1 中调用 S 安全侧 API,API 返回前没有出现线程调度

  • Case2:应用线程 1 中调用 S 安全侧 API,但是 API 返回前出现了线程调度,切换执行线程 2 任务,线程 2 没有调用 S 安全侧 API

  • Case3:应用线程 1 需要调用 S 安全侧 API,但是 API 返回前出现了线程调度,切换执行线程 2 任务,线程 2 也调用 S 安全侧 API

2.2.1. Case1:Thread1 调用 S 安全侧 API,返回前没有出现线程调度

第一种情况比较简单,在这个场景中 Thread1 会调用 S API,在其运行期间 CPU 会切换到 S 安全侧执行,S API 函数执行结束后返回 NS 非安全侧的 Thread1 继续执行,整个过程中没有出现线程调度,如图 4 所示。

4.png


这是一个相对简单的情况,因为 Thread1 调用 S API 的整个过程没有被打断,因此看起来 RTOS 内核不需要做特殊处理,线程可以正常执行。但是这里需要注意的一个问题是线程的 stack,因为当 Thread1 调用 S API 切换至 S 安全侧执行的时候,CPU 使用的堆栈将不再是 NS 非安全侧的线程堆栈(PSP_NS 所指向的 RAM 地址),而是会切换使用安全侧的堆栈(PSP_S 或者 MSP_S 所指向的位于 RAM 安全区的地址)。如果 RTOS 内核要管理线程stack,那么对于需要调用 S API 的那些线程,还需要管理他们在安全侧要用到的 stack。在这种 case 中,只要安全侧 API 函数有局部变量需要用到堆栈,RTOS 内核就需要为Thread1 分配 S 安全侧的内存,并且管理其对应的 PSP_S,以便 Thread1 需要调用 S API的时候,将能够使用 PSP_S 所指向的 S 安全侧的线程堆栈。

2.2.2. Case2:Thread1 调用 S 安全侧 API,返回前出现线程调度

第二种情况比第一种情况略微复杂,在这个场景中 Thread1 依旧会调用 S API,在其运行期间由于时间片切换等原因,CPU 会切换到 S 安全侧执行,但是 S API 函数执行尚未结束就出现了线程调度,NS 非安全侧 RTOS 内核的调度器将挂起 Thread1,并切换到Thread2 执行,Thread2 执行一段时间后再次出现线程调度,回到 Thread1 继续执行,如图5 所示。

5.png


我们知道通常情况下在 ARM CM33 内核进入调度器中断时,当前线程的上下文会压栈到PSP,调度器可能还会压栈其他一些寄存器的内容到 PSP 指向的 stack 中,然后通常会把当前线程 Thread1 的 PSP 指针记录在对应线程的数据结构中,接下来找到下一个需要启用的线程 Thread2,恢复 Thread2 的 PSP,这样从调度中断返回的时候,EXC_RETURN 加载到 PC,系统会回到线程模式,从 Thread2 的 PSP 指向的 stack 恢复线程上下文,继续从Thread2 执行。

但是我们现在讨论的情况是内核使能了安全扩展,也就是 CPU 在 TrustZone 环境下运行,这时候进入线程调度中断时,EXC_RETURN 中除了有常规的数据,还同时记录了额外的信息,其中包括上下文压栈的使用的 stack 是 S 还是 NS 的指示。在上述的 Case2 场景中,Thread1 被打断时 CPU 正运行在 S 安全状态,EXC_RETURN 将标记压栈使用 S 安全侧 stack,当调度器恢复了 Thread2 的 PSP,系统从线程调度中断返回时,按照EXC_RETURN 的标记,CPU 将回到 S 安全态执行,而不是执行 Thread2 的上下文,这样会造成问题。所以对于这样的情况,RTOS 的内核调度需要对 EXC_RETURN 做处理,需要记录线程的 EXC_RETURN 值,在调起某个线程的时候,也要恢复对应的 EXC_RETURN,以便从中断退出时能够进入正确的线程运行状态(S 安全或者 NS 非安全)。

2.2.3. Case3:Thread1 调用 S API,返回前出现线程调度,Thread2 也调用 S 

API第三种情况更加复杂,在 Case2 的基础上,如果 Thread2 也需要调用 S API,那么Thread2 也会切换到 S 侧执行,如图 6 所示。

6.png


这种情况中,Thread2 切换到 S 侧时,需要使用 Thread2 对应的安全侧 stack,当切换回 Thread1 时,需要使用 Thread1 对应的安全侧 stack,因此 RTOS 内核的线程调度器需要有能力为每个线程记录并恢复 PSP_S,而运行在 NS 非安全侧的 RTOS 内核线程调度器无法直接访问 PSP_S,因此,RTOS 内核也需要有 S 安全侧的一部分代码,来协助完成线程PSP_S 的记录和恢复操作,这样第三种情况会变成类似图 7 的样子,RTOS 线程调度器在S 安全侧也有一部分配合线程切换的代码,来管理线程的安全侧 PSP_S 的记录与恢复。

7.png


总结对上述三种情况的分析,我们可以看到,完整支持 CM33 内 TrusZone 的 RTOS 内核需要能够处理多个线程调用 S API 的情况,这可能包括对 EXC_RETURN 的处理,以及管理那些可能调用 S API 的线程在 S 安全侧需要使用的 stack 空间的分配以及以及对 PSP_S的操作和管理。那么实际中 TrustZone 环境下 NS 侧使用 RTOS 的样子可能如图 8 所示,RTOS 提供的上层功能如 thread,mutex,semaphore,message queue 等依旧是在非安全侧,由非安全侧应用程序使用,但是 RTOS 内核的调度器还有一部分代码运行于安全侧,用于配合辅助不同情况下的线程调度。

8.png

三、TrustZone 环境中 NS 非安全侧使用 RTOS 的注意事项

首先需要注意 RTOS 的版本,比较旧的版本可能还没包含对 ARM CM33 内核以及TrustZone 的支持。如果应用的项目是从某个过去的项目中迁移到 STM32MCU 的新产品,尤其使用了 TrustZone 的时候,建议检查原始工程中的 RTOS 版本,确认是否已经包含对CM33 内核以及 TrustZone 的支持。

其次,要注意在安全和非安全工程中添加正确的 RTOS 代码。以 FreeRTOS 为例,它的portable 代码有多个目录,在 TrustZone 环境中应当使用 ARM_CM33 目录下的文件。

9.png


同时这个目录下又有两个子目录,分别对应 secure 和 non-secure,在构建应用工程的时候除了要添加 NS 非安全工程中的 FreeRTOS 代码外,还需要在安全工程中添加对应的secure 目录下的 FreeRTOS 代码。例如在 IAR 中工程包含的 FreeRTOS 源代码文件中将会类似图 10 所示。

10.png


最后还要注意的一点是关于安全侧的 stack 分配。如果 NS 非安全侧线程需要调用安全侧API,那么通常需要为该线程分配安全侧的 stack,该 stack 的大小由 S API 函数所需要的stack size 决定。依旧以 FreeRTOS 为例,FreeRTOS 提供了新的 API,用于线程分配其在安全侧的堆栈,需要调用 S API 的线程应当在其线程主函数的开始旧调用函数portALLOCATE_SECURE_CONTEXT(),分配安全侧的 stack,如图 11 所示。

11.png

四、小结

本文重点讨论了基于 ARM CM33 内核的 STM32MCU 支持 TrustZone 的环境下使用RTOS 的一些情况,并总结了 TrustZone 环境下使用 RTOS 的一些注意事项。某些 RTOS如果没有对 TrustZone 的非常完整的支持,使用起来可能会有些限制,这时候应用程序可能需要注意。例如通过添加 mutex 避免多个线程同时调用 S API 等。当然这里仅仅讨论了 NS侧使用 RTOS 的情况,也就是 S 安全侧只是提供函数由非安全侧调用,本身安全侧没有调度器没有线程概念,如果安全侧也包含了调度器(比如 TF-M)那么配合非安全侧使用RTOS 可能会是另一种情况。

本文是 STM32MCU TrustZone 开发技巧的系列文章的最后一篇,希望对开发者有所帮助,也欢迎大家多提宝贵意见。

来源:STM32

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

围观 18

01、概述

在 STM32 系列 MCU 中, 除了一些特殊管脚外,绝大多数管脚都可以分类为 FT (兼容5V 信号)或 TT(兼容 3V3 信号)类型的 IO,由于 MCU 内部设计的不同, TT IO 相比 5V IO 有更多的限制,下面我们将予以说明。

02、TT 和 FT IO 的结构和参数区别

下面我们解释 TT 和 FT IO 的不同内部结构以及因此导致的对输入电压和电流的不同限制要求。

2.1. TT 和 FT IO 的结构区别

下面的图 1 描述了 TT 和 FT IO 的通用结构:

1.jpg

图1.TT/FT IO 的内部结构

TT 和 FT IO 的内部结构在 IO 端口的保护电路 (IO 到 VSS 二极管以及 ESD 保护单元),输出 BUFFER,数字控制单元以及模拟单元都是相同的。 

区别在于, 对于 FT IO 来说,从 IO 输入到模拟单元之间存在一个模拟开关,只有在软件控制相关寄存器后这个开关才会闭合. 而对 TT IO 来说, 这一模拟开关是不存在的,IO 管脚与模拟单元直接相连。

2.2. 结构不同导致对电平和电流的不同要求

从图 1 结构图中可以看到, 在 IO 内部的模拟单元中存在一个输入信号到 VDDA 寄生二极管和相串联的电阻,该二极管是寄生的,因此其电流能力是无法保证的,不但不能用做模拟输入信号的钳位二极管,而且还要避免任何从输入信号到 VDDA 的注入电流的产生, 否则可能导致内部相关电路的损坏。 

因此对于 FT IO 的数字输入信号来说, 由于模拟开关被断开, 输入的信号即使高于VDDA 也不会导致模拟单元中寄生二极管电流的产生,在 VDD+4V 的范围内, IO 是安全的。 

如果 FT IO 被配置为模拟输入,模拟开关闭合, 那么它就不再是兼容 5V 的 IO 了,输入信号的幅度必须小于 VDDA+0.3V。 

对于 TT IO 来说,由于不存在到模拟单元的模拟开关,模拟单元的寄生二极管和 IO 口是直接相连的,因此,在任何时候都必须保证加到 TT IO 端口的信号电平小于VDDA+0.3V。 

另外需要补充的是,如果 IO 输入信号可能存在负电平,尽管 TT 和 FT 类型的 IO 都在端口处设计有到 VSS 的二极管,这一二极管提供了一定的钳位保护能力,但是其通过电流能力限制在 5mA 以下。因此,外部钳位二极管通常仍然是必须的,如果不能通过外部钳位二极管将输出负电平信号限制在大于 -0.3V, 那么就需要串联限流电阻将流经二极管的负注入电流限制在 5mA 以下。

2.3. STM32 datasheet 中相关参数说明

在 STM32 的 datasheet 中对 IO 端口的电压和注入电流的要求有限制, 以STM32G474 为例, 在 Absolute maximum ratings 章节中, IO 对输入信号电压的要求如下:

2.jpg

图2.IO 对输入信号电压的要求

很多人注意到了电压要求,认为只要加在 FT IO 的信号电平不超过 VDD+4V, 加在TT IO 的电平不超过 4V 都是安全的, 但是忽视了 IO 对工作电流和注入电流也有要求, 电流方面的要求也必须得到满足, 具体如下:

3.jpg

图3. IO 对电流方面的要求

可以看到, IO 对注入电流同样有着限制,在-5mA 到 0 之间,超出这一范围仍然可能造成 IO 的损坏。 

对于 STM32 的使用来说, 电平和电流方面的限制必须都得到满足。

03、TT IO 的注意事项

使用者对加在 IO 的电平幅度限制一般都能遵守,但是对于 IO 电流特别是注入电流的严格限制往往被一些使用者忽视,然而实际上, IO 对注入电流的限制往往对加在 IO 管脚的信号电平提出了更高的要求。

对于 FT 类型 IO 来说, 只要信号电压在使用的合理范围内,正的注入电流是不可能产生的。 

对于 TT 类型 IO 来说, 超过 VDDA+0.3V 的信号电压都有可能产生 大于 0mA 的正向注入电流,这个电流流过芯片内部参数没有保证的模拟单元寄生二极管,从而可能导致电路损伤。 

因此对 TT IO 的电平 小于 VDDA+0.3V 的限制在任何场景下都必须满足。 

一个常被忽视的场景是系统上电时, 在 STM32 的供电系统还没有建立时, STM32 的IO 信号已经加在了 IO 管脚,例如某些电源或电机应用中对母线电压的检测,通常用分压电阻将母线电压分在 1V~2V 之间后连接到 STM32 的某一 ADC 采样输入 IO,通常这一分压电压到达 IO 比 VDD 建立更早。如果这一 IO 是 FT 类型的, 那么 IO 的信号电平始终能满足 小于 VDD+4V 的要求, 不管 VDD=0V 或 3V3。但是假如这一信号所接的是 TT 类型的 IO, 那么在 VDD=0 或低电平时, 母线电压分压后的电平将超过 VDDA+0.3V 的限制,带来芯片损坏的可能。 

为了避免 TT IO 损坏,在系统上电,下电或工作的整个过程中, 必须始终满足 TT IO 端口电平 小于 VDDA+0.3V 的要求. 当 TT IO 的信号电平可能超过 VDDA+0.3V 时, 钳位保护电路是必须的。

在上述母线电压检测的案例中, 如果这一检测管脚不得不使用 TT IO, 那么一个从信号到 VDDA (或同电位的其它电源)的钳位二极管将可以防止 VDD=0 等场景下信号电平超范围的可能。

04、小结

在 IO 管脚的使用中, 电平限制和电流包括注入电流的限制必须同时得到满足。 

TT IO 由于内部结构的原因,更容易产生正的注入电流而给 IO 带来损坏。注入电流的限制给 IO 端口的信号电平带来了更严格的要求。 

在使用中, 必须考虑信号电平的时序,确保在任何场景下 TT IO 的信号电平满足小于VDDA+0.3V 的要求, 必要时可以通过钳位电路来达到这一目的。

来源:STM32单片机

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

围观 23
一、引言

在 STM32 TrustZone 开发调试技巧 | 地址安全区及资源安全属性配置文章中,我们介绍了内核的 SAU/IDAU,地址的安全属性配置,资源的安全属性配置,以及内核访问资源的安全规则等内容,这部分作为 TrustZone S/NS 工程开发的基础,让 S 和 NS 工程代码能够基本运行起来。

在此基础上,S/NS App 还需要使用片上外设等资源,实现应用程序的业务逻辑和功能,这时候往往会遇到一些与外设使用相关的问题。

在这一篇中,我们将把重点放在 Trust Zone 架构下应用开发中使用外设的环节,从外设中断、DMA、GPIO 及其与 IO 连接的外设等几个方面,介绍这些部分与传统的不带TrustZone 的 STM32 开发相比有哪些变化,同时会列举一些相关开发中的常见问题,并给出问题的分析与解决方法,供开发者参考。

二、关于外设中断

2.1 CM33 内核 TrustZone 架构下的中断

2.11 中断向量表 Vector Table

传统的 ARM V6/V7 内核,例如 CM4、CM7,都只有一套中断向量表,而带 SecurityExtension 的 CM33 内核有两套中断向量表,分别对应 CPU 的 S 和 NS 两种状态,如图 1所示。在 TrustZone 的双工程开发中,S 工程和 NS 工程都会有各自的中断处理程序(interrupt handler)。他们也有各自的 VTOR,即 VTOR_S 和 VTOR_NS。体现在 linker 文件中,也都有各自的 initial vector 的地址和向量表部分。

系统上电复位后,CPU 总是处于安全状态,因此一定首先从 Secure 的 Reset Handler开始执行代码。当 S 代码完成相关的初始化和系统配置之后,通常会跳转至 NS 代码的Reset Handler 开始执行 NS 代码。但是这里的 NS Reset Handler 其实并不是真正意义上的 interrupt handler,因为没有任何中断会直接进入这个 Handler,它仅仅是 S 代码跳转NS 代码时候的跳转入口。当发生系统复位时,硬件会忽略 NS 的 reset handler 和初始SP。系统永远都是复位到 Secure,加载 Secure 的初始 SP,并从 Secure 的 ResetHandler 开始执行。图 2 给出了 TrustZone 环境下的代码执行顺序示例。

1.png

▲ 图1 带 TrustZone 的 CM33 内核的两个中断向量表

2.png

▲ 图2 TrustZone 环境下的 S/NS 代码运行顺序示例

内核的两个 Vector table 中都包括系统中断和外设中断两个部分,系统中断里有一部分是 bank 的,也就是说 S 和 NS 各有一套,互不相干,例如 Systick,PendSV,SVCall,MemoryFault,Usage Fault,这些中断的 handler 可以在 S/NS 中被各自触发,各自有各自的处理程序。有些中断只会出现在 S 侧,例如 SecureFault,而 HardFault,NMI,BusFault 则默认在 S 侧,但可以通过寄存器配置,允许 NS 侧触发相关的异常。

2.12 外设中断

中断表中的最后一类则是外设中断,即图 1 中 IRQx。这类中断属于目标二选一的中断。上电复位缺省所有 IRQx 都是 target 到 S 的,即任何一个 IRQx 都只会触发 Vectortable S 里面的中断句柄,NS 侧虽然也有同样的 IRQx 和对应的 handler,但是并不会被触发。为了能够选择 IRQx 的 target 目标世界,NVIC 中增加了一组寄存器 NVIC_ITNS0 -NVIC_ITNS15,用于指定某个 IRQx 是否 target 到 NS。上电复位后,ITNSx 寄存器默认值总是 0,也就是所有 IRQ 都 target 到 S,如果需要让某个 IRQ 触发 NS 侧的中断句柄,则需要将对应的 ITNSx 的 bit 设置为 1。

具体设置方法有两种:

  • 调用函数NVIC_SetTargetState(IRQn)设置某个 IRQ 为 target 到 NS;

  • 直接操作 NVIC 的 ITNS 寄存器,例如 NVIC->ITNS[x] = xxx,这种方式比较便捷,且可以一次设置多个 IRQ 的不同 target 目标。

在 STM32 CubeFW 软件包的 TrustZone Template 工程中通常我们会看到一个与TrustZone 有关的配置文件,文件名类似 partition_xxxx.h,这个文件里面会包含 SAU 的配置,中断的 Target 配置等等。其中,中断 target 的配置就是通过直接写 NVIC->ITNS[x]寄存器的方式完成的。需要修改配置的时候只需要定义相关的 NVIC_INIT_ITNSx 宏并修改 NVIC_INIT_ITNSx_VAL 的值即可。例如

#define NVIC_INIT_ITNS0 1 
#define NVIC_INIT_ITNS0_VAL 0xFFFFFC7F

2.2 NS App 中 IRQ Handler 无法进入问题

有很多时候,客户可能是将原有其他 STM32 系列的平台上已经开发过的应用移植到CM33 内核带 TrustZone 的 STM32 产品上,通常原有的业务逻辑会放在 NS 非安全侧,安全侧则主要实现一些与信息安全相关的功能。也有可能项目本身就是在支持 TrustZone 的STM32 MCU 上进行的开发,但是刚开始并没有使能 TrustZone 功能,后面再把TrustZone 使能起来,进行完整的开发和集成。这时候,开发者往往会遇到 NS App 的外设中断无法触发的问题。

【问题现象】NS App 外设中断在不使能 TrustZone 的环境下都能够正常工作,但是移到 TrustZone使能的环境之后,发现 NS App 的外设中断总是无法被触发,例如 UART 中断,GPIO EXTI 中断,DMA 中断等等。如果在调试器中将断点设置在中断句柄函数中,则会发现本来硬件应当触发中断的时候,NS App 的 IRQ handler 却从未进入。

【分析】CM33 TrustZone 架构下,内核有两套中断向量表,上电复位所有的 IRQ 都缺省Target 到 S,也就是说,不做特别配置的话,外设中断只会触发 S 侧的 IRQ Handler,因此 NS App 的 IRQ Handler 一定不会有响应。通常在 Trust Zone 开发中发现 IRQ 中断句柄应当被触发却并未被触发,应当首先检查该 IRQ 的安全目标配置是否正确。

【解决方法】在 S 工程的初始化代码中,将需要被 NS App 处理的 IRQ 都配置为 target 到 NS,可以参考 2.1.2 小节的相关说明。

这种问题往往出现在开发者直接手写代码(或者从 STM32CubeFW 软件包的TrustZone 模板工程开始)进行 TrustZone 配置的时候,因为需要配置的点可能比较多,又未必是集中在同一个代码文件中,有可能忽略了某个配置,造成问题。如果选择使用STM32CubeMX 工具生成相关的工程框架和初始化代码,用 GUI 界面的方式进行配置,则会更加简单明了,相对来说会降低出错几率。在第 5 章节中将对这部分加以简要介绍。

三、关于 DMA

3.1  DMA 的 TrustZone aware 特性

STM32 MCU 中的 DMA 单元(例如 GPDMA, LPDMA)在 Trust Zone 框架下属于 TZaware IP,DMA 能够直接支持 AHB5 总线。

作为总线主设备,DMA 可以发出 S 安全或者 NS 非安全的 transaction。以 STM32U5GPDMA 为例,通过 GPDMA_SECCFGR.SECx 寄存器,可以将 DMA 的 Channel 设置为安全或者非安全通道。

如果一个 Channel 具有安全属性,那么它就是一个安全 DMA 通道,Secure DMAChannel 有能力发出 S 安全或者 NS 非安全访问,同时,S 安全代码还可以配置安全 DMA通道的 source 和 destination 数据传输的安全访问属性,安全通道对 source 和 destination的安全访问属性配置是独立的,互相之间没有依赖关系,因此配置为安全的 DMA 通道可以任意地在安全或者非安全资源之间做数据搬移,如图 3 所示。红色表示非安全访问/非安全资源,绿色表示安全访问/安全资源,从图中可以看到安全 DMA 可以访问所有不同安全属性的 source 和 destination,包括 Flash,SRAM,外设等。

这里要注意一点,如果安全 DMA 通道访问的资源是存储器,那么安全通道配置的source 和 destination 的安全属性应当与目标资源的安全属性一致,否则无法正常访问资源的数据,会出现 RAZ/WI 的效果。

3.png
▲ 图3 安全 DMA Channel 可以访问安全或者非安全资源

注意:当使用 DMA 的 link list 模式时,从 memory 中读取 link list 表数据结构时的安全访问属性与 Channel 的安全属性一致。所以 Secure Channel 加载 link list 表时,读取memory 也使用安全访问模式。

如果一个 Channel 配置为非安全属性(这也是上电复位后 DMA 的缺省状态),那么非安全 DMA Channel 只能发出 NS transaction,只能在 NS 属性的资源之间做数据搬移,

如图 3 所示。如果非安全 DMA 通道试图访问安全资源,将无法正常读写数据,通常效果是 RAZ/WI。


4.png

▲ 图4 非安全 DMA Channel 只能访问非安全资源

作为总线从设备,DMA 的寄存器被访问时,也能够识别总线上的安全访问标志信号HNONSEC,根据 Channel 的安全、非安全属性会允许或者阻止对某些寄存器的访问。

当某个 Channel 被设置为 Secure,NS 代码尝试读取 Secure Channel 的寄存器会返回 0,某些寄存器除外,例如 GPDMA 的 GPDMA_SECCFGR,GPDMA_PRIVCFGR 和GPDMA_RCFGLOCKR 可以被非安全代码读取。NS 代码尝试写 S DAM Channel 的寄存器将没有任何效果。

除了安全、非安全属性,DMA Channel 还可以配置其 PRIV/NPRIV 属性(特权/非特权模式访问)。依旧以 STM32U5 GPDMA 为例,GPDMA_PRIVCFGR.PRIVx 寄存器用于配置某个 Channel 的特权模式访问属性。当某个 Channel 配置为特权模式时,这个Channel 的寄存器也只能被特权模式访问,包括读和写。某些寄存器可能存在例外,例如GPMDA 的 GPDMA_PRIVCFGR, GPDMA_SECCFGR,GPDMA_RCFGLOCKR 可以被NPRIV 模式读取。

PRIV 属性的 Channel 发出的访问都是 PRIV 特权模式访问,NPRIV 属性的 Channel发出的访问都是 NPRIV 非特权模式访问。

注意:当使用 link list 模式时,从 memory 加载 link list 表数据结构时候的访问模式与Channel 的 PRIV/NPRIV 属性一致。

当 DMA 对资源进行读写的时候,任何一个访问都会带有 S/NS 以及 PRIV/NPRIV 属性,因此 DMA 通道的 Secure 属性和 PRIV 属性配置是共同起作用的,他们会同时体现在DMA 对资源访问的 transaction 中。图 5 给出了两种 Channel 以及 Channel 对source/destination 访问可能携带的 Secure 和 PRIV 标记的例子。Channel1 是 S+PRIV 通道,Channel2 是 NS+NPRIV 通道。当然还有可能出现其他的组合,例如 S+NPRIV 通道和 NS+PRIV 通道。DMA 访问 source 和 destination 时的 PRIV/NPRIV 属性直接遵循Channel 自身的 PRIV/NPRIV 属性,所以无论对 source 还是 destination,DMA 发出访问的 PRIV/NPRIV 属性一定是相同的;访问的 S/NS 属性在 NS Channel 中只能是 NS 访问,对 source 和 destination 都一样,而在 S Channel 中可能出现 S 或者 NS 访问,且source 和 destination 访问的安全属性可能不一样。


5.png
▲ 图5 DMA Channel 的 Secure+PRIV 属性组合示例

3.2 TrustZone 架构下带有 DMA 的 Securable 外设

STM32 MCU 中可能含多个具有 DMA 功能的硬件单元,并不是所有的带 DMA 功能的硬件都是 TrustZone aware 外设。系统中除了有作为独立的总线主设备出现的GPDMA/LPDMA 等之外,还可能包含其他一些带有 DMA 功能的总线主设备,例如SDMMC、Ethernet、DMA2D 等。这些设备在使用过程中也有可能通过自身的 DMA 进行数据搬移。但是他们并不是 TZ aware 外设。

在 TrustZone 使能的环境中,这类主线主设备一般是 Securable 外设,他们并不具备像 GPDMA/LPDMA 那样的对 TrustZone AHB5 总线及 HNONSEC 信号直接支持的能力。

作为 Securable 总线主设备,他们的 TrustZone 特性通过 GTZC TZSC 的 PPC(Peripheral Protection Controller)来支持。具体说就是通过配置 TZSC 的 SECCFGRx寄存器可以让某个 Securable 外设具有安全或者非安全属性,通过配置 TSZC 的PRIVCFGRx 寄存器可以设置 Securable 外设的 PRIV/NPRIV 属性。

具体到这些总线主设备,当使用他们的 DMA 功能做数据搬移时,DMA 发出的读写操作在总线上的访问方式就取决于 SECCFGRx、PRIVCFGRx 对这个 IP 的配置。

以 SDMMC 举例

  • SDMMC 被配置为 NS+NPRIV 属性(一般这是外设上电默认所具有的安全属性),那么它的 DMA 访问就都是 NS+NPRIV 属性的。

  • SDMMC 被配置为 S+PRIV 属性,那么它的 DMA 访问都是 S+PRIV 的。

  • 当然也可以是另外的两种组合:NS+PRIV,S+NPRIV。

当这类 IP 的寄存器作为总线从设备被访问的时候,它的一般访问规则是:Secure IP只允许 Secure 访问,NonSecure IP 允许 Secure 或者 NonSecure 访问;PRIV IP 只允许PRIV 访问,NPRIV IP 允许 PRIV 或者 NPRIV 访问。图 6 给出了带 DMA 功能的Securable IP 的寄存器的安全访问规则,以及他们的 DMA 发出的 transaction 与 IP 自身的Secure/PRIV 属性的关系。类似于 TZ aware 的 DMA,当使用 link list 模式时,DMA 从memory 加载 link list 表项数据结构的时候,对 memory 的 Secure/PRIV 访问属性与 IP 自身的 Secure/PRIV 属性配置也一致。

6.png
▲ 图6 Securable IP 的 Secure/PRIV 属性及 DMA 访问具有的安全属性

3.3 TrustZone 环境下使用 DMA 的常见问题

本小节总结了几个在 TrustZone 项目中使用 DMA 遇到的问题,可能也是比较常见的一类问题,给开发者做参考。

3.3.1. 问题 1:NS App 无法驱动 DMA Channel

【问题现象】NS App 需要使用 DMA,用于 SPI 数据传输,应用中已经有相关初始化代码,但是代码运行后 App 无法控制 GPDMA Channel0。

【分析】初始化配置后观察 DMA Channel 的寄存器,发现 GPDMA_SECCFGR 的 bit0 为 1,也就是说 DMA Channel0 被设置为了 S 安全通道。这样 NS App 肯定就无法控制Channel0 的寄存器,肯定不能正常驱动 DMA Channel0。

进一步查看 S App 的代码,客户使用了 TF-M 用来提供安全侧的一系列服务。在 TF-M代码中缺省使能了针对 TrustZone 隔离的一些测试功能,其中包括 DMA Channel 访问的测试,而这部分代码会在初始化阶段将 DMA Channle0 配置为 S+PRIV 属性,这导致了NS App 无法驱动 DMA Channel0。

【解决方法】由于 S App 实际并不使用 DMA 实现应用功能,仅仅是为了测试目的,因此可以关闭这段与测试相关的置 DMA Channel0 为 Secure Channel 的初始化代码,保持 DMA Channel0 的 NonSecure 属性,这样 NS App 就可以正常操作这个 DMA 通道了。

3.3.2. 问题 2:NS App 中 DMA link list 模式无法正常工作

【问题现象】NS App 需要使用 SRAM1,片外 PSRAM,DCMI 以及 DMA 等。DMA 需要对PSRAM 数据进行搬移,并且使用了链表结构。在 S 工程中已经将需要的资源配置为NonSecure,且 NS App 能够正常运行起来。但是 DMA 无法按照 link list 的数据定义完成数据搬移。

【分析】通过调试发现,初始化后,DMA 的配置都可以正常完成,SRAM1 中也有正确的 link list 链表数据,但是当 DMA 完成第一组搬移后,需要从链表数据结构中加载下一组搬移配置时,链表数据加载完成后,对应 DMA 寄存器的值是 0。这说明 DMA 没有从 SRAM1 中正确加载链表数据。

由于 NS App 本身需要使用 SRAM1,而 NS App 是可以正常执行的,这说明 SRAM1已经配置为 NS 属性,允许 NS 访问。进一步查看代码发现,S 工程中对 SRAM1 的GTZC MPCBB 配置中,仅仅配置了 NS 属性,而 SRAM 上电默认具有 S+PRIV 属性,也就是说,经过 GTZC MPCBB 对 SRAM1 的配置,SRAM1 的属性为 NS+PRIV,因此不允许 NPRIV 的访问。而 GPDMA Channel 上电默认属性为 NS+NPRIV。那么他做任何访问都只能是 NS+NPRIV 属性。这解释了为什么 DMA 从 SRAM1 中加载链表数据结构时出错。

【解决方法】要解决问题这个问题,只要保证 DMA 的访问权限等于或者高于被访问目标允许的访问权限就可以。那么修改方法有两个:

  • 在 S 工程中将 SRAM1 配置为 NS+NPRIV 属性,NS App 代码保持不变。

  • 在 NS App 中添加代码,设置 DMA Channel 为 PRIV 属性。

这两种方法都可以让 NS App 中的 DMA 成功完成链表模式的数据搬移操作。

在这个小节的内容中我们可以看到 DMA 在 TrustZone 架构下有额外的安全访问配置,当然这些配置可以通过直接手写代码完成,其实也可以通过 STM32CubeMX 工具在图形界面中完成所有的配置。这样产生的初始化代码更加容易保持配置的一致性。在第 5 章节中也会对这部分做出简要介绍。

来源:STM32

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

围观 23

在工业4.0与智能制造的大背景下,工业物联网发展迅猛,越来越多的设备具备了连接能力,大量数据在物联网与互联网之间传递,这使得信息安全成为嵌入式联网设备越来越需要关注的话题。信息安全涉及的知识和技术可能非常广泛而复杂,在嵌入式系统中实现安全性往往成为开发者的一个负担。有没有方法帮助开发者减轻这样的负担?这是ST试图通过STM32Trust来回答的问题,STM32Trust是一项专注于提高设备安全性以及为非专家开发者提供安全专业知识而带来的所有软件和硬件解决方案的计划。

开发人员可能需要让产品的安全设计能够满足安全认证的要求,与此同时也希望更快地实现设备的信息保护,帮助工程师意味着我们要让ST的工具以及解决方案更易于使用。为此ST采取的举措之一就是在2023年初宣布的Secure Manager安全管理器解决方案,九月份Secure Manager安全管理器已经正式发布了第一个版本,STM32H5便是Secure Manager所支持的第一款STM32 MCU。让我们来快速回顾一下什么是安全管理器,它能如何帮助到开发者在他的产品中快速实施安全保护。

STM32 TEE可信执行环境解决方案Secure Manager安全管理器

Secure Manager是ST率先推出的以二进制形式提供的TEE可信执行环境(Trusted Execution Environment)解决方案,也是能够在系统级别达到SESIP和PSA 3级安全认证目标的(先进)解决方案。由于该方案提供的是二进制文件而非源代码,可以省去大量的开发和集成时间,大大加快产品的认证过程。Secure Manager采用可下载软件包的形式提供,其中包含二进制文件、库、代码实现和文档等。

目前Secure Manager已经发布了支持STM32H5的第一个正式版本,欢迎访问网址https://www.st.com/en/embedded-software/stm32trustee-sm.html 了解更多有关STM32 TRUSTEE Secure Manager的详细信息,也可以从该网页下载X-CUBE-SEC-M-H5软件包。

最易获取的STM32安全解决方案

以前,对于安全保护方案,ST提供的是STM32的硬件特性以及以源代码形式交付的软件(例如获得了PSA和SESIP Level3认证的STM32U5 TF-M方案),这意味着开发人员必须自己完成一些客制化和适配集成的工作,如果产品有认证需求,可能还需要再次对代码进行验证,因为很多时候,原有的认证只有在代码保持不变的情况下才继续有效。而以二进制文件形式提供的Secure Manager安全管理器恰恰解决了这个问题。此外,Secure Manager安全管理器提供了一个交钥匙解决方案,可以自动启用并设置安全启动功能ST-iRoT和ST-uROT,并且直接从TrustZone的安全侧提供安全存储、加解密和Attestation等安全功能,实施安全解决方案的过程变得格外简单。开发者只需要关注如何调用相关API使用安全管理器已经提供的功能,而无需开发安全侧的服务,他们可以将更多的精力用于客户应用程序的开发。

此外,客户不必担心这个安全解决方案的维护问题,Secure Manager完全由ST拥有并进行维护,我们将会在需要的时候编写和发布新版本或者补丁。由于工作流程大大简化,即使是对于在安全方面拥有丰富专业知识的团队,这样的方案也会收到欢迎。事实上,除非产品有着非常特殊的需求,否则使用ST的二进制文件可以节省大量的时间和资源。Secure Manager还提供了安全管理器访问工具包(或SMAK--Secure Manager Access Kit),以帮助开发人员创建运行在TrustZone环境非安全侧的应用程序,并使用安全管理器的服务。

面向高级用户的全面的解决方案

ST在设计新的Secure Manager方案时也考虑到了灵活性,因此,允许经验丰富的开发人员自定义他们的解决方案。除了SMAK,Secure Manager还提供开发工具包(SMDK--Secure Manager Development Kit),可以帮助开发者创建复杂的可信应用程序(TA – Trusted Application)。例如,一个开发指纹算法的团队可以使用SMDK将算法变成一个TA 可信应用模块,这个可信应用可以装载到Secure Manager安全管理器中,成为运行在TrustZone安全侧的一个特权级可信应用,非安全侧的应用程序能够调用这个可信应用提供的服务。

此外,得益于ST-iRoT和Secure Manager提供的服务,程序员可以在STM32H5中存储密钥和证书,让嵌入式系统轻松注册并连接到云服务器,免去使用外部硬件安全模块等繁琐问题。Secure Manager的加解密API还允许程序员使用密钥对敏感数据进行加密和解密,而无需访问密钥本身,从而保护它们免受攻击。

1.jpg

上图是STM32 Trusted Execution Environment 可信执行环境Secure Manager安全管理器的框架示意框图。图的右半边属于TrustZone的安全侧,其中蓝色的部分是安全管理器默认提供支持的部分,包括安全启动ST-iROT/ST-uROT和基础安全服务,无需开发;粉红色的部分则是基于SMDK开发的可以安装在安全管理器中运行的扩展安全应用,这部分客户可以自己开发,也可以使用来自第三方的开发好的安全应用。使用STM32H5 的安全管理器,意味着从安全启动、安全升级到默认的安全应用都已经准备好,无需开发与适配。图的左半边属于TrustZone的非安全侧,其中黄色的部分才是客户需要自己开发的应用业务逻辑。

近期STM32MCU生态系统中的STM32CubeProgramer和STM32CubeMX等工具也进行了更新,发布了新版本,其中增加了支持STM32H5的新安全特性和Secure Manager的一系列功能,配合安全管理器SMAK的首个正式版本发布。例如STM32的初始化软件STM32CubeMX中增加了启动路径配置选项,可以指导开发人员激活某些安全功能,如STM32H5的iRoT,生成可以直接配合Secure Manager的应用工程框架等。最新的STM32Cube工具也可以很方便地从STM32 Developer Zone入口快速下载。(附下载链接)

最后再给大家推荐几个STM32MCU的wiki链接,方便读者详细了解STM32H5的安全特性、Secure Manager解决方案、以及如何在STM32CubeProgrammer、STM32CubeMX等工具中配置和使用STM32H5的安全特性、功能与解决方案。

来源:STM32

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

围观 26

页面

订阅 RSS - STM32