嵌入式newlib-nano printf导致硬错误

Question

我在2个目标上编译“相同”代码（一个飞思卡尔，一个STM32都使用cortex M4）。我使用--specs=nano.specs并将_write函数实现为空函数，这会导致整个printf被GCC的-Wno-unused-function优化掉，即使-O0也是如此在STM32目标上（见地图）。这很好，我想在飞思卡尔目标上重现它。

但是在飞思卡尔目标（具有相同的编译标志）上，printf会导致严重错误。但是，如果我一步一步地使用调试器（汇编步进），printf将通过库而不进行硬件调试。简单断点断点有时不会从printf中的任何位置点击并运行导致硬错误（因此它不太可能是外围问题）。

到目前为止，我检查了堆栈和堆没有重叠和其他一些牵强的反汇编。

为什么在freescale目标上没有优化printf？ 什么可能导致库代码硬错？ 为什么在逐步调试时进行组装是否正常？

编辑：

• 对于具有相同库的两个MCU使用arm-none-eabi-gcc 5.4.1。
• 我不想删除printf，这只是能够使用的第一步 他们与否。
• 向量表有所有ISR的默认弱向量，所以它应该没问题
• 使用register dump似乎故障指令位于地址4（复位向量），所以现在出现了新的问题：为什么芯片会复位？

Answer 1

当ARM应用程序在使用printf之前似乎正常工作时，最常见的问题是堆栈错位。在调用printf的函数的入口点放置一个断点并检查堆栈指针。如果指针不是双字对齐的，那么您已经找到了问题。

Answer 2

使用newlib在printf中崩溃的常见原因是错误地设置了免费存储，尤其是在使用RTOS（即FreeRTOS）的情况下。自2019年以来，恩智浦（以前称为飞思卡尔）将我的解决方案包含在MCUXpresso中。您可以在这里找到代码和详细说明：https://github.com/DRNadler/FreeRTOS_helpers