为什么第 13 行的代码会导致 Hard Fault？

发表于 2025-5-30 23:00

#include "stm32f0xx.h"void SysInit(void); uint8_t array1[260] = {0};uint8_t array2[260] = {0};uint16_t test;int main(void) { SysInit(); for(uint16_t i = 0; i < 260; i++) array1[i] = i & 0xFF; test = *(uint16_t*)&array1[0xEA]; test = *(uint16_t*)&array1[0xEC]; test = *(uint16_t*)&array1[0xEB]; while(1);}void SysInit(void) { FLASH->ACR |= FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY; RCC->CR2 |= RCC_CR2_HSI48ON; while(!(RCC->CR2 & RCC_CR2_HSI48RDY)) {}; RCC->CFGR &= ~(RCC_CFGR_PPRE | RCC_CFGR_HPRE | RCC_CFGR_SW); RCC->CFGR |= RCC_CFGR_PPRE_DIV16 | RCC_CFGR_HPRE_DIV1 | RCC_CFGR_SW_HSI48; while((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_HSI48) {}; RCC->CFGR &= ~RCC_CFGR_PPRE; RCC->CFGR |= RCC_CFGR_PPRE_DIV1; SystemCoreClockUpdate();}

数组array1 的所有其他有效读数都正常工作（ 0xEB 除外）。几乎尝试了所有方法。（volatile、optimizer、additional variables、memory aglin 等）
此代码可在其他 ARM 设备上正常工作。

发表于 2025-5-31 16:58

你把8位数组的地址强制转换成16位整型的指针，指针是按两个字节寻址的，0xEB其实已经数组越界了，至于说为什么Hard Fault，这可能跟编译器有关。

发表于 2025-5-31 23:38

尝试读取非对齐地址将导致硬件 HardFault，或者读取失败（返回错误数据），视编译器行为和内存对齐策略而定。

发表于 2025-6-9 11:42

在STM32F0系列微控制器上，访问数组时出现Hard Fault通常是由于内存访问越界或对齐问题引起的

发表于 2025-6-9 12:30

STM32F0系列微控制器要求对uint16_t类型的访问必须是对齐的。也就是说，uint16_t变量的起始地址必须是2的倍数。在你的代码中，array1是一个uint8_t数组，访问array1[0xEB]和array1[0xEC]时，你试图将它们转换为uint16_t指针。

发表于 2025-6-9 13:28

array1[0xEB]的地址是array1 + 0xEB，0xEB的二进制是11101011，所以地址不是2的倍数。

发表于 2025-6-9 14:00

array1[0xEC]的地址是array1 + 0xEC，0xEC的二进制是11101100，地址是2的倍数。因此，array1[0xEB]的访问是不对齐的，可能导致Hard Fault

发表于 2025-6-9 14:30

使用memcpy：如果需要从非对齐地址读取数据，可以使用memcpy将数据复制到一个对齐的缓冲区中

发表于 2025-6-9 16:52

使用memcpy，对于非对齐访问，使用memcpy来安全地复制数据

发表于 2025-6-9 19:00

对齐访问，在STM32F0系列中，确保对uint16_t的访问是对齐的

发表于 2025-6-9 22:00

调试和测试，使用调试工具和日志输出，确保代码运行符合预期

发表于 2025-6-9 23:00

你修改一下数组对齐试试呢？感觉你这不对劲啊

发表于 2025-6-12 01:00

确保对uint16_t的访问是对齐的。你可以通过检查索引：确保对uint16_t的访问索引是偶数

[STM32F0] 为什么第 13 行的代码会导致 Hard Fault？

相关帖子

浏览过的版块

浏览过的版块