MCU学习笔记系列
- 1. ADC+DMA 目标数组无更新 解决办法 (个人博客链接) (CSDN链接)
- 2. ARM Cortex-M内核中DMA内存地址对齐的影响与效率权衡 (个人博客链接) (CSDN链接)
- 3. ARM原子操作 (个人博客链接) (CSDN链接)
- 4. ART-PI在KEIL的使用教程(个人笔记) (个人博客链接) (CSDN链接)
- 5. ART-Pi开发者的福音：一个“宝藏级”实践仓库，点亮你的学习之路 (个人博客链接) (CSDN链接)
- 6. CUBE 配置SDRAM 无法选择地址问题解决办法 (个人博客链接) (CSDN链接)
- 7. CUBEMXV6 (个人博客链接)
- 8. FEERTOS的TICKLESS模式下最大低功耗的时间只能是349tick的原因分析 (个人博客链接) (CSDN链接)
- 9. FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍：从原理、代码到适用边界 (个人博客链接) (CSDN链接)
- 10. FREERTOS开启TICKLESS后最大只能349tick休眠的原因分析 (个人博客链接) (CSDN链接)
- 11. HAL_DMA_ERROR_FE错误代码解决方法 (个人博客链接) (CSDN链接)
- 12. ISO 14229 (Unified Diagnostic Services, UDS) 诊断工具实现(can_uds) (个人博客链接) (CSDN链接)
- 13. KEIL5 编译器AC6 使用RT-THREAD操作系统 使用组件CmBacktrace方法+addr2line使用 (个人博客链接) (CSDN链接)
- 14. M104BPCSX-5024 RFID 驱动与应用层开源实现分析 (个人博客链接) (CSDN链接)
- 15. MAX14830 可移植 C 驱动实现分析：一个适合多串口扩展场景的开源基础版本 (个人博客链接) (CSDN链接)
- 16. MCU内核电压不稳导致程序跑飞的现象、原因与影响 (个人博客链接) (CSDN链接)
- 17. Qboot V2：让 Bootloader 从“能升级”走向“可持续演进” (个人博客链接) (CSDN链接)
- 18. RT-Thread 使用设备驱动框架 驱动看门狗例程中 MSH命令后提示“find iwg failed“”解决办法 (个人博客链接) (CSDN链接)
- 19. RT-Thread调试利器：get_irq_priority——像Keil一样在MSH中查看和设置中断优先级 (个人博客链接) (CSDN链接)
- 20. RTT各种错误排查（个人方法） (个人博客链接) (CSDN链接)
- 21. SPI通信模式及其对DMA控制器配置策略的影响 (个人博客链接) (CSDN链接)
- 22. STM32CubeIDE 调试“失灵”之谜：别动那个关键的复选框 (个人博客链接) (CSDN链接)
- 23. STM32F7 使用 FAL 配置片上FLASH (个人博客链接) (CSDN链接)
- 24. STM32H7系列微控制器SPI FIFO阈值配置对高速数据传输稳定性的影响 (个人博客链接) (CSDN链接)
- 25. STM32系列微控制器DMA寄存器写入失败的解决方法 (个人博客链接) (CSDN链接)
- 26. STM32高性能DMA架构解析：MDMA与DMA的核心差异及最佳实践 (个人博客链接) (CSDN链接)
- 27. stop2模式低功耗无法进入的问题分析 (个人博客链接) (CSDN链接)
- 28. Vscode ESP-ID 添加自定义组件解决办法 (个人博客链接) (CSDN链接)
- 29. >- (个人博客链接)
- 30. 【ARM V6编译器 编译汇编代码出错解决办法】 (个人博客链接) (CSDN链接)
- 31. 一个开源的CANopen转Modbus网关 (个人博客链接) (CSDN链接)
- 32. 一次由 C 位域非原子写入引发的状态上报异常 (个人博客链接) (CSDN链接)
- 33. 不止是驱动：一个专心设计的、基于“构建器”模式的传感器管理框架 (个人博客链接) (CSDN链接)
- 34. 关于RTC的玄学bug分析与解决 (个人博客链接) (CSDN链接)
- 35. 数据异常值检测利器：Grubbs‘检验的C语言实现 (个人博客链接) (CSDN链接)
- 36. 由于 Cortex-M 栈未满足 8 字节对齐导致的问题与原因分析 (个人博客链接) (CSDN链接)
- 37. 结合QBoot与HPatchLite实现高效差分升级（FOTA） (个人博客链接) (CSDN链接)
- [38. 面向 MCU 与 RTOS 的 Newlib、Newlib-nano、`–specs=nano](<./%E9%9D%A2%E5%90%91%20MCU%20%E4%B8%8E%20RTOS%20%E7%9A%84%20Newlib%E3%80%81Newlib-nano%E3%80%81%60–specs%3Dnano.specs%60%20%E4%B8%8E%20%60_REENT_SMALL%60%20%E8%AF%B4%E6%98%8E.md>) (个人博客链接)
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 wdfk-prog的个人博客！
微信- 支付寶
相关推荐
2025-10-03
HAL_DMA_ERROR_FE错误代码解决方法
[toc] 错误场景： 使用STM32F7芯片 使用CUBE生成配置 使用如下链接代码 https://download.csdn.net/download/qq_39665253/77125064 具体为DMA+USART+FIFO（软件编写）+双串口。将接受到的数据发送回串口助手中。 表面上看收发正常。实际应用时（MODBUS多从机应用），总会丢失数据。debug看串口错误中断，发现EeeoreCode错误代码为10如何定位进入错误中断前的代码，看下面链接 https://blog.csdn.net/u013181595/article/details/69523331 定位进入错误中断代码，可找到这段代码。即进入了FIFO错误中断了观察CUEB串口设置，并没有使用FIFO。 CUBE生成代...
2026-06-29
由于 Cortex-M 栈未满足 8 字节对齐导致的问题与原因分析
# 由于 Cortex-M 栈未满足 8 字节对齐导致的问题与原因分析 @[toc] 嵌入式工程中，栈对齐通常不会被单独拿出来讨论。很多 Cortex-M 工程长期使用 4 字节对齐的内存访问，也能正常启动、跑任务、处理中断，因此“栈必须 8 字节对齐”看起来不像一个硬性问题。真正容易暴露问题的场景，往往出现在变参函数、64 位数据、浮点参数、启动阶段 C 代码、异常入口，以及手写汇编与编译器生成代码混用的边界上。 这篇文章从规定开始，解释为什么 Cortex-M 工程需要关心栈的 8 字节对齐；再说明不满足时可能出现什么现象；最后给出不同工具链脚本的查看方法和修改方法。 一、规定：公开接口处 SP 必须 8 字节对齐AAPCS32 是 Arm 32 位架构的过程调用标准。它规定函数之间如何传参、如何返回、哪些寄存器由调用者保存、哪些寄存器由被调用者保存，以及栈指针需要满足什么约束。 在 AAPCS32 中，栈有两层约束： 位置 要求 含义 任意时刻 SP mod 4 = 0 栈指针至少按字对齐 函数公开调用边界 SP mod 8 = 0 栈指针必须按双字对...
2026-06-17
面向 MCU 与 RTOS 的 Newlib、Newlib-nano、`--specs=nano
@[toc] 面向 MCU 与 RTOS 的 Newlib、Newlib-nano、--specs=nano.specs 与 _REENT_SMALL 说明 适用对象：使用 GCC/Arm GNU Toolchain、RT-Thread、FreeRTOS、Zephyr 或类似 MCU RTOS 的嵌入式 C/C++ 工程。重点问题：newlib 是什么、为什么 MCU 工程会链接它、newlib-nano 如何减少体积、--specs=nano.specs 和 _REENT_SMALL 的作用与风险，以及如何不选用 newlib 而改为工程自实现或替换部分函数。 1. 结论先行在 MCU/RTOS 工程里，newlib 可以理解为 GCC 裸机/嵌入式工具链常用的 C 标准库实现。它提供 memcpy、memset、strlen、printf、snprintf、malloc、free、errno、time、strtok 等标准 C 或类 POSIX 接口，但它并不知道你的硬件上有什么 UART、文件系统、heap、线程或设备驱动。...
2026-04-01
MCU内核电压不稳导致程序跑飞的现象、原因与影响
@[toc] MCU内核电压不稳导致程序跑飞的现象、原因与影响 一、问题概述本次异常的本质不是单纯的软件逻辑错误，而是内核供电不稳定引发的系统级异常。当芯片内部核心电压不能被稳定维持时，CPU、总线、外设控制逻辑都会受到影响，最终表现为程序执行异常，也就是现场常说的“跑飞”。 这类问题通常具有较强的迷惑性：表面看像是线程异常、定时器异常、偶发 HardFault，甚至像软件定时或中断处理有问题；但实际根因在于供电相关电路未按规格书要求正确连接，导致内核工作电压不稳定。 二、典型现象内核电压不稳时，系统通常不会一上电立即完全失效，而是表现出一定的随机性和偶发性，常见现象包括： 1. 运行一段时间后随机异常系统上电后可以启动，基本功能初期也可能正常，但运行一段时间后会突然出现异常，表现为： 程序卡死 线程调度异常 某些任务不再按预期运行 定时行为紊乱 2. 异常位置不固定问题出现时，表面上的故障点往往并不一致，例如： 有时记录在线程上下文 有时表现为中断处理异常 有时进入 HardFault 有时停在某个看似无关的函数或流程中 这类“落点不固定”的问题，正是供电不稳的典型特...
2026-03-30
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍：从原理、代码到适用边界
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍：从原理、代码到适用边界先看核心结论FNV-1a 64-bit 的重点，不是“32 位 MCU 能不能跑 64 位整数”，而是下面三件事： 这个散列为什么能工作。 代码实现里每一步到底在做什么。 哪些场景适合用，哪些场景不适合用。 把这三件事讲清楚后，再讨论 32-bit 和 64-bit 的工程取舍，结构会更稳，也更接近实际选型过程。 FNV-1a 的标准更新过程可以概括成一条固定循环： 状态从 offset_basis 开始 每读取一个字节，先异或进状态 再乘上固定的 FNV_Prime 运算结果保留在固定比特宽度内 对 64-bit 版本，标准常量是： 12#define FNV1A64_OFFSET_BASIS 0xCBF29CE484222325ULL#define FNV1A64_PRIME 0x00000100000001B3ULL 这两个常量不是任意挑选出来的。offset_basis 决定初始状态，FNV_Prime 决定每次吸收新字节后如何扩散已有状态。 先把原...
2026-03-21
一次由 C 位域非原子写入引发的状态上报异常
@[toc] 一次由 C 位域非原子写入引发的状态上报异常在一套嵌入式控制固件中，出现过一类很典型、但又很容易被忽略的异常：传感器物理状态已经持续触发，心跳报文却长时间仍然上报为 0；重新手动触发一次后，状态又恢复正常。 表面上看，这类问题很像采样抖动、消息队列满、或者 CAN 发送延迟。但沿着发送链路继续深挖后，真正的问题并不在总线，也不在消息队列，而是在 C 语言位域写入不是原子操作 这一点上。 先看现象，不要先怪 CAN异常表现有几个很强的特征： 传感器已经进入触发状态，并且维持了很长时间。 心跳报文仍然持续发送，但目标状态位始终是 0。 再次手动触发一次传感器后，状态恢复正常。 不是“完全没报文”，而是“报文一直有，但某一位一直不对”。 这类现象说明一件事：发送通道本身大概率是通的。如果 CAN 队列、发送线程、或总线仲裁是主因，更常见的表现会是丢帧、延迟、或整帧不发，而不是“整帧一直发，但某一位长期错误”。 因此，排查重点不该先放在“是否发出去”，而应该放在“发出去的那 8 个字节是谁构造的，以及构造时有没有被并发写坏”。 位域写入通常是读改写，不是原子更...
评论
