之前想试试看板卡卡死的原因是否是flash擦除的时候触发中断挂起正好卡死的 因为网上也看过很多相关的言论 于是实验 将flash擦除函数放在sram里执行 同时进行GPIO翻转

将flash擦除函数替换为

attribute((section(".RAM_CODE"))) void SRAM_ErasePageAndBlink(uint32_t pageAddr) { static uint32_t count = 0; count++;

// 启动页擦除 FLASH->CR |= FLASH_CR_PER; FLASH->AR = pageAddr; FLASH->CR |= FLASH_CR_STRT; // 改 TIM17 计数，让他触发 TIM17->CNT = TIM17->ARR;

// 改 DMA 计数，让他完成 NVIC_SetPendingIRQ(TIM17_IRQn); DMA2_Channel4->CNDTR = 1; TIM5->CNT = TIM5->ARR; if(count >= 10) { GPIOE->ODR ^= GPIO_PIN_5; count = 0; } while(FLASH->SR & FLASH_SR_BSY); FLASH->CR &= ~FLASH_CR_PER; }

这样计划是可以实现在擦除的时候把中断挂起 看看CPU会不会卡死 遗憾的是 PE5的LED会正常反转 flash正常擦除 同时这并不会导致CPU卡死 想了解一下平常所说的 擦除flash时触发中断会导致cpu卡死 到底是什么原因导致CPU卡死呢

在实验的时候发现这种操作挺危险的 处理不好很容易进hardfault 比如没有等待擦除完就直接执行指令

在 Flash 擦除/编程期间，只要 CPU还要访问正在忙的 Flash，就会发生 bus stall（总线停顿）；代码取指、数据读取、向量表取址都会被阻塞，直到擦除/编程完成后才恢复执行。

如果想在 Flash擦写期间继续执行，必须把相关内容 全部放到 RAM，包括：

• 启动擦写的代码
• 所有相关中断处理函数
• 中断向量表
  

否则即使你把中断处理函数和向量表搬到了SRAM，如果发起Flash 擦写的代码本身还在Flash 中，执行仍可能因为Flash 忙而停住。

主要风险是“暂停/卡住/响应超时”，而不是“因为中断发生就必然运行错误”。

但在工程上，这种停顿仍然可能间接引发功能异常，例如：
   1.实时中断来不及处理
    2.通信超时
    3.看门狗喂狗不及时
    4. 控制环中断抖动或失步

这些属于 由长时间 stall 带来的系统级后果；

通常处理的方式有两类：

1. 在 Flash 擦写期间禁用中断，在编程/擦除期间关闭中断，避免中断打断后又去访问 Flash。

2. 必须并行运行的代码全部搬到RAM

如果你必须在擦除期间继续响应某些中断，那么需要把下面内容都放到RAM：

   Flash 擦写发起代码
    中断向量表
    ISR
    ISR 调用到的函数，以及会访问的相关数据/常量

<br /> <br />

上面所说的风险操作不能用于工程实践中，代码的执行不能阻断自己的后续执行

你关心的重点应该是有没有一个固定的卡死机制存在，是吧。

肯定没有必然出现卡死的机制存在，但有可能出现卡死情况。

比方基于中断方式的ADC，因为临时堵塞导致数据没法达到预期值，影响程序的逻辑判断。

或者，因为临时导致正常情况下不会出现的溢出或出错事件，触发了中断，但中断里又根本没有相关标志的清零整理，导致FLASH完毕后中断无限循环的跑，卡死正常程序。这都是有真实案例发生的。