我在 2 个目标上编译了“相同”的代码(一个是飞思卡尔，一个是 STM32，都带有 cortex M4)。我使用 --specs=nano.specs 并将 _write 函数实现为一个空函数，这会导致整个 printf 得到优化远离 GCC 的 -Wno-unused-function 即使在 STM32 目标上使用 -O0(见 map )。这很好，我想在飞思卡尔目标上重现它。
但在 Freescale 目标(具有相同的编译标志)上，printf 会导致硬故障。但是，如果我使用调试器(汇编步进)一步步进行，printf 会在没有硬故障的情况下通过库。简单断点断点有时不会从 printf 中的任何位置命中并运行也会导致硬故障(因此不太可能是外围问题)。
到目前为止，我检查了堆栈和堆没有重叠以及其他一些牵强的反汇编。
为什么 printf 没有针对飞思卡尔目标进行优化？ 什么会导致库代码出现硬故障？ 为什么组装的时候一步一步debug就OK了？
编辑:
- 对具有相同库的两个 MCU 使用 arm-none-eabi-gcc 5.4.1。
- 我不想删除 printf，这只是能够使用的第一步 他们与否。
- vector 表有所有 ISR 的默认弱 vector ，所以应该没问题
- 使用register dump错误指令似乎在地址 4(复位 vector )处，所以现在的新问题是:为什么芯片会复位？
最佳答案
当 ARM 应用程序似乎在使用 printf 之前正常工作时，最常见的问题是堆栈未对齐。在调用 printf 的函数的入口点放置一个断点并检查堆栈指针。如果指针不是双字对齐的，那么您就发现了问题。
关于c - 嵌入式 newlib-nano printf 导致硬故障，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46399152/