问题已找到，是偶尔在特殊情况下没有调用FATFS_UnLinkDriverEx函数，导致disk.nbr一直等于1的情况下，再次调用FATFS_LinkDriverEx函数，从而导致disk.drv[disk.nbr] = drv时，相当于disk.drv[1]= drv，内存溢出；这是因为_VOLUMES定义为1，disk.drv[1]是不存在的数组变量
通常，我们做IAP设计时使用 两个相对 独立的工程，分别是BOOTLOADER和APPLICATION区。 前者重点是接收固件代码、完成Flash编程。后者通常是实际的用户功能性应用程序代码。 显然，很多外设，比方UART/TIMER/GPIO以及核外设NVIC，可能在BOOT区和APP区都会用到。 但各用各的，配置及初始化也是根据当前工程需要具体配置，外设配置、变量定义跟在另外一个 运行区没有关联。 具体点说，即使同一个UART，BOOT区可以配置8bit 115200，APP区可以配置为7位 9600。两个代码区的UART收发 缓冲定义其实也是各自定义、各不相干。 一般来讲，中断矢量表位置也是各定义各的。即不同代码区的中断矢量入口地址都是相互独立的。以UART中断服务程序为例， 即使服务程序代码一样，发生中断事件时，中断服务程序的入口是不一样 的。其中，Cortex-M0核芯片稍微特殊点,另当别论。 Bootloader中的全局变量和静态变量在跳转到APP后不再有效，因为APP会重新初始化自己的全局变量和静态变量。反之亦然。 不过，如果说在当前代码区使用了动态内存分配（例如malloc），跳转到另一代码区后，这些内存估计仍然占据着内存 空间，我们可以在跳转前先行释放这些内存。
STMCU-管管
回答时间：2024-11-25 13:30
SAR ADC模块是一种模数转换器，用于将模拟信号转换为数字信号。SAR ADC模块通常提供内部通道（Internal channel）、测试通道（Test channel）和外部通道（External channel）。SADC可以在微控制器处于低功耗模式时继续工作，无需唤醒整个系统。普通ADC提供更高的分辨率和采样率，适用于需要精确测量的应用。SADC可以用于周期性检查，而普通ADC用于在需要时进行精确测量。
从编译提示来看，说handle_GPDMA1_Channel11没有被定义。 你检查下是否相应DMA配置完整没有？ 使用CubeMx配置完成后，会在main.c里定义这个变量： DMA_HandleTypeDef handle_GPDMA1_Channel11; 再看看中断处理文件里是否有： Extern DMA_HandleTypeDef handle_GPDMA1_Channel11; 或许将工程重新创建一次啥事也没有了。
问题可能出在DMA配置或DMA传输的相关代码及逻辑，这里给些应用提醒供参考： 1、确保DMA配置正确，包括源地址、目标地址、数据长度等。 2、在启动DMA传输之前，确保所有数据都已经准备好： 3、确保屏幕的刷新率与DMA传输速率匹配； 4、是否有其他代码处理方面的问题，尤其是跟DMA有关的，比方DMA中断处理。。。
如果你使用LL库就调用 SysTick_Config(); 如果使用HAL库就调用HAL_SYSTICK_Config(）； 基于cubeMx创建工程是不会有啥问题的。自己创建工程的话，建立完整即可，别缺这个少那个。
我用过外部中断唤醒的方式，在进入STOP模式前，清除所有外部中断标志位，其他（比如systick）不做处理，是正常没问题的。另外可以检查下WAKE_UP引脚的上下拉状态，是不是一直处于唤醒电平。
这个话题说起来有点长。 在STM32HAL库里定义很多状态变量，用于对各自外设模块的状态管理，比方ready,busy,idle,timeout,error等， 以便正确使用各个外设，避免使用上的混乱。 以usart为例，库里为USART的发送、接收操作分别定义了两个状态变量，即gState和RxState。其中gState表示USART的发送状态，RxState表述接收时可能的状态。 是ready还是busy或其它出错、超时状态。USART初始化后gState为reddy状态，当要调用UART发送函数时软件将其设置为Busy. 当usart完成发送或中止发送时，软件将gState设置回Ready。 如果说你调用的查询式发送函数，即HAL_UART_Transmit(），则在该函数里查询到数据发送完毕或发生超时都会将gState设置为Ready. 如果说你调用的是中断式发送函数，即HAL_UART_Transmit_IT（），同时你沿用CubeMx创建的中断服务程序代码框架，在相应的发送中断服务程序 里检测到发送完毕时，也会将gState修改为ready为下次发送做准备。 如果说你调用API函数是HAL_UART_Transmit_IT（），而中断服务程序是另外组织的， 要记得在发送完成时将gState改为Ready，不然下次调用HAL_UART_Transmit_IT（）函数会因为gstate检查不通过而不能得以执行。 如果说你调用的是DMA方式发送函数，即HAL_UART_Transmit_DMA(),同样，也沿用CubeMx创建的中断服务程序代码框架，且开启了DMA完成中断和UART事件的中断， 在相应的DMA完成中断代码里也会适时地将gState从busy改为ready。如果说，你虽然调用了HAL_UART_Transmit_DMA()函数，但没有开启DMA完成中断， 也没有在适当的位置将gState改为ready，这时就会发生即使你多次调用HAL_UART_Transmit_DMA()函数而只会做一次发送的情形。因为在后续的 HAL_UART_Transmit_DMA()函数里做gState检查发现是busy而强行退出。当然，这时手动将其改为Ready也是可以的，但要保证合适的时间点。 比方，我就是不想开启DMA相关中断，只是想通过DMA方式发送几次字符串而已，像下面这样 HAL_UART_Transmit_DMA(&huart2, (uint8_t *)String1, sizeof(String1)); HAL_Delay(200); huart2.gState = HAL_UART_STATE_READY; huart2.hdmatx->State = HAL_DMA_STATE_READY; __HAL_UNLOCK(huart2.hdmatx); HAL_UART_Transmit_DMA(&huart2, (uint8_t *)String2, sizeof(String2)); HAL_Delay(200); huart2.gState = HAL_UART_STATE_READY; huart2.hdmatx->State = HAL_DMA_STATE_READY; __HAL_UNLOCK(huart2.hdmatx); 当然，这里还有一种情况，尽管当我们基于中断或DMA方式调用UART发送，也开启了相关中断并沿用库函数的写法，还是可能出现只有第一次发送有效的 情况，比方像下面这样： HAL_UART_Transmit_DMA(&huart2, (uint8_t *)String1, sizeof(String1)); HAL_UART_Transmit_DMA(&huart2, (uint8_t *)String2, sizeof(String2)); HAL_UART_Transmit_DMA(&huart2, (uint8_t *)String3, sizeof(String3)); 这里的三次调用太近了，第一次调用时软件将gstate改为busy，当运行第二个第三个调用时，第一次的uart发送可能根本没有完成，自然也就没法 基于它的完成中断将gstate改为ready，这样导致后续的两次调用都无效了。所以像这种情况，第二次调用前要确保上次传输完成了。 整体上，上面分析了两种可能的情形，请结合你的代码检查下，看看是哪种原因或是还是别的什么原因。 DMA发送函数只能第一次调用有效？
输出手册里有个关于各个外设的功耗表格，类似下面的： 如果使用ADC的，至少得开启ADC和相关管脚GPIO的时钟，如果说用到DMA的话，DMA也要增加功耗。你可以结合上面表格估算下。
第一次发帖，不知道为什么，发上去的时候，代码变得这么乱；按道理应该不需要重新映射地址的，两片FLASH交换之后，地址也互相交换了，我理解应该是将BIN文件直接写入到FLASH2的起始地址，然后交换FLASH，重启就可以了。!(data/attachment/forum/202411/21/093427x3288aq254ql9774.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
微信公众号
手机版
.png)
