【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

【本文为安富莱电子原创】

本期的知识点要稍微烧点脑细胞,因为字节对齐问题涉及到的地方太多,且无法规避,必须硬着头皮上。

下面要说的每个技术点,其实都可以专门开一个帖子说,所以我们这里的讨论,争取言简意赅,并配上官方文档和实验数据,力求有理有据。如果讲解有误的地方,欢迎大家指正,我们主要讨论M0,M0+,  M3,M4和M7内核。



一、引出问题:

字节对齐的含义:4字节对齐的含义就是变量地址对4求余数为0; 8字节对齐就是地址对8求余等于0,依次类推:

比如
uint32_t *p;
p=(uint32_t *)0x20000004; 这个地址是4字节对齐。

如果让p去访问0x20000001, 0x20000002,0x20000003这都是不对齐访问。



二、背景知识:

对于M3和M4而言,可以直接访问非对齐地址(注意芯片要在这个地址有对应的内存空间),  因为M3和M4是支持的,而M0/M0+/M1是不支持的,不支持内核芯片,只要非对齐访问就会触发硬件异常。

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

M7内核也支持非对齐访问,在M7的TRM中描述如下:
【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)




三、全局变量对齐问题:

基本上用户定义的变量是几个字节就是几字节对齐,这个比较好理解。

uint8_t定义变量地址要1字节对齐。
uint16_t定义变量地址要2字节对齐。
uint32_t定义变量地址要4字节对齐。
uint64_t定义变量地址要8字节对齐。

指针变量是4字节对齐。

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)


四、结构体成员对齐问题:

首先明白一点,结构体里面的变量是什么类型,此变量的位置就是至少要几字节对齐,所以就存在结构体实际占用大小不是这些变量之和。

typedef struct
{
        uint8_t a;
        uint16_t b;
        uint32_t c;
        uint64_t d;        
}info;

这种定义,info占用了16字节,a单字节对齐,b是两字节对齐,而c要是4字节对齐,从出现b定义完毕后空出来1个字节未被使用。d是8字节对齐,这样就是16字节。而我们切换下变量定义顺序:
typedef struct
{
        uint16_t b;
        uint32_t c;
        uint64_t d;        
        uint8_t  a;
}info;

这种定义就要占用24字节,b占用2字节对齐,c需要4字节对齐,这样就空出来2两个字节未使用,d占用8字节,最后一个a占用了8字节。

如果想定义几个变量就几个字节,变量前面加前缀__packed即可。

不管是上面那种定义方式,都是占用15个字节。

__packed typedef struct
{
        uint8_t a;   1个
        uint16_t b; 2个
        uint32_t c; 4个
        uint64_t d; 8个        
}info;



五、局部变量对齐问题:

局部变量使用的是栈空间(除了静态局部变量和编译器优化不使用栈,直接用寄存器做变量空间),也就是大家使用在xxxx.S启动文件开辟的stack空间。

在M内核里面,局部变量的对齐问题如果研究起来是最烧脑的,这个涉及到AAPCS规约(Procedure Call Standard for the Arm Architecture,  Arm架构的程序调用标准)。

 【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

上面这个贴图最重要,仅需理解上面这两条就可以,意思是说,栈地址是全程至少保持4字节对齐的,因为M内核的硬件长做了处理,SP最低两个bit,bit0和bit1直接固定为0了。

但是在程序调用入口处必须满足8字节对齐,对于C语言,不需要用户去管,编译器都帮我们处理好了,先来个简单的示例压压惊:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

而汇编文件是需要用户去处理的。以xxx.S启动文件为例,通过伪指令PRESERVE8来保证

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

那么问题来了,我们搞个4对齐是不是会出问题,一般情况下也没问题的,但特殊情况下不行,特别调用C库的sprintf和printf函数,直接给你输出个不知所以然的结果来。比如我在H7上做如下测试:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

输出结果:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)




六、中断服务程序的栈对齐问题:

先来看两个图:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

通过这两个图我们了解到:M0/M0+/M7的栈地址是固定8字节对齐,M3/M4的栈地址是对齐是可以通过SCB->CCR寄存器编程的为4字节或者8字节对齐。

比如我们设置的8字节对齐,那么中断发生的时候,如果SP指针位置在4字节对齐,那么硬件自动插入4字节来保证8字节对齐,之后就是硬件自动入栈的寄存器开始存入栈中。

另外就是不同的M内核硬件版本,这个地方略有不同,这个大家作为了解即可,早期的内核硬件版本应该没什么人用来做芯片了。
【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

七、硬件浮点对齐问题

如果使用的是带FPU硬件浮点单元的M内核芯片就要注意对齐访问了,访问单精度浮点数访问一定要4字节对齐,双精度要8字节对齐。

比如我们使用支持单精度浮点的M4内核芯片,测试代码如下:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

MDK直接给你来个不对齐硬件异常:

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)



八、RTOS的任务栈:

RTOS的任务栈涉及到双栈指针问题,SP(R13寄存器)有两个栈指针,MSP主栈指针和PSP进程栈指针。简单的说,我们在中断服务程序里面都是用的MSP,而任务里面用的PSP。

优势是方便任务和中断栈空间分别管理,了解了这点知识就够了。

RTOS任务栈的关键依然是8字节对齐问题,如果仅仅是满足4字节对齐,就会出现我们前面printf和sprintf浮点数或者64bit数据的错误问题,早年各种RTOS移植案例还不是那么发达的时候(现在问题依旧),经常在这个地方入坑,加上硬件浮点寄存器入栈出栈后更是玩不转了。

比如大家搜索关键词 uCOS printf 或者uCOS 浮点数,一堆的问题,平时不用浮点不知道,一用浮点,各种问题就来了,特别是多任务都使用浮点计算,更是懵。

根本原因是底层移植文件的堆栈8字对齐有问题,很多人都是采用的指令__align(8)来设置堆栈对齐问题,其实修改底层port文件才是解决问题的根本。

为什么会造成这个问题,根本原因依然是前面AAPCS规约的要求,RTOS的移植都有个汇编的port文件,这个port文件的关键是实现任务切换,任务切换的关键就是进入任务前保证PSP是8字节对齐。

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)



九、DMA对齐问题:

DMA对齐指的是源数据地址和目的数据对齐问题。这个问题最容易出错的地方就是网上倒腾SD卡移植FatFS的SDIO DMA方式。

大家网上搜关键词FatFS SDIO DMA,也是一瓢的问题,特别是BMP等格式图片显示的时候,这种问题就来了,因为很难保证每次的读取都是4字节对齐的。

以STM32F4的DMA为例,我们的底层移植无需再单独开一个缓冲做4字节对齐,本质是F4 DMA支持了源地址和目的地址的数据宽度可以不同,但是数据地址必须要跟其数据类型对齐。

比如使用SDIO DMA从SD卡读取数据,我们就可以设置源地址依然是4字节对齐(外设访问要4字节对齐),而目的地址设置为字节对齐,就可以方便的解决4字节对齐问题。

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

其实不仅是通用的DMA,像图形加速DMA2D,SDMMC自带的IDMA等都有这种问题。



十、配置MPU造成的对齐问题:

这个问题主要是对于M7内核芯片来说,以STM32H7 TCM以外空间为例:AXI RAM(0x2400 0000),
SRAM1(0x3000 0000),
SRAM2(0x3002 0000),
SRAM3(0x3004 0000),
SRAM4(0x3800 0000),
SDRAM等做非对齐访问都会有硬件异常,而开启Cache就不会有问题。

这个问题的关键就是M7的TRM中这句话:

意思是,如果用户使用MPU将H7的AXI总线下的内存空间配置为Device 或者 Strongly-ordered模式,用户采用非对齐方式访问,将会触发UsageFault

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

 

实际测序下,果然会触发这个异常

【烧脑技术贴】无法回避的字节对齐问题,从八个方向深入探讨(变量对齐,栈对齐,DMA对齐,结构体成对齐,Cache, RTOS双堆栈等)

 

配置内存空间的MPU属性为Device 和 Strongly-ordered以外的属性就可以解决此问题了。

上一篇:DMA与ADC的配置


下一篇:STM32LL库系列教程【四】——DMA实现ADC单通道采集