keil5 compiler6 -o1读取内部flash硬件错误的问题

问题说明

最近在做gd32E230c8t6 BootLoader的时候，发现当打开编译优化-o1的时候，代码运行不正常。

代码会在读取内部flash内存时出现问题，进入了hardfault。但是改为-o0后，运行就正常了。非常诡异，后面经过反复测试逐步摸清楚了问题的原因。先看问题的代码

uint8_t temp[PAGE_SIZE];
void run_bootloader(void)
{
	...
	flash_read(FLASH_SAVE_ADDR_APP,temp,PAGE_SIZE); 
	...

}
1
2
3
4
5
6
7
8

其中PAGE_SIZE=1024.这段代码的意思很简单，就是将FLASH_SAVE_ADDR_APP后的1K字节读取到temp数组中。flash_read函数内容如下。

int flash_read(uint32_t addr,uint8_t *buf,uint32_t len)
{

//	printf("buf addr:%x %x",(uint8_t*)buf,addr);
    for(uint16_t i = 0;i<len;i+=4)
    {

		*( uint32_t*)&buf[i] =*(volatile uint32_t*)(addr+i);
    }
    return 0;
}
1
2
3
4
5
6
7
8
9
10
11

flash读取是4字节读取，一次读取4字节，这里将buf强制类型转换成了uint32，当i=0时，上述一次赋值相当于将buf[0],buf[1],buf[2],buf[3]进行了赋值，提高了代码的效率。从逻辑上这样做一点问题都没有，但是-o1确出现了问题。

问题原因分析

采用-o1编译，最明显的好处是代码占用空间会急剧减小。下图展示了采用-o1和-o0编译的代码大小，可以看出，采用-o1代码从9k变成了4k。由于gd32E230c8t6 只有64k，所以要尽量减少BootLoader的空间占用，把有限的空间尽量让给app。

分析问题最好就是硬件debug了
采用-o1编译，其debug如下：

汇编代码分析：
( uint32_t)&buf[i] =(volatile uint32_t)(addr+i);
这行赋值转换成汇编就是两句话；
0x08000336 581C LDR r4,[r3,r0]
0x08000338 50CC STR r4,[r1,r3]
这两句话的意思是 r3寄存器的值加上寄存器r0的值，该值实际上是一个地址为：0x08009400。然后将0x08009400地址上的值取出来放入寄存器r4.（0x08009400即为设定的FLASH_SAVE_ADDR_APP）

第二句话的意思是，将寄存器r4里面的值（0x20000640）存放到 r3寄存器的值加上寄存器r1的值，该值的地址。就是说将0x20000640写入内存地址0x2000001A。

这里逻辑上也没啥问题，关键是运行完这一句话之后，就进入了hardfault。

那再来看看-o0时的汇编代码

仔细分析下最后也是将0x20000640存入了地址0x2000001C里面。可以看出没有用-o1代码执行效率低了很多。

通过查看map文件可知，-o1时，temp数组的首地址为0x2000001A；-o0时，temp数组的首地址为0x2000001C；

这段代码的区别就是首地址不一样。arm默认内存都是4字节对齐，因为数据总线也是按照4字节访问，而上述的1a不是4的倍数，1c是4的倍数。也就是说1a不是4字节对齐所以不能强制内存转换为uint32.这样就导致了硬件错误。经过多次验证确实这这个问题。

当-o1优化时，因为定义的temp数字是uint8，没有进行4字节对齐，而是进行了2字节对齐。这种就不能用内存强制转换为4字节。

问题修复

既然找到了原因，那就只需要修改掉flash_read函数即可。

int flash_read(uint32_t addr,uint8_t *buf,uint32_t len)
{
//	printf("buf addr:%x %x",(uint8_t*)buf,addr);
    for(uint16_t i = 0;i<len;i++)
    {
		buf[i]=*(volatile uint8_t*)(addr+i);
    }
    return 0;
}
1
2
3
4
5
6
7
8
9