2

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

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

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

为什么 printf 没有在 freescale 目标上优化？什么会导致库代码出现硬故障？为什么一步步调试组装就可以了？

编辑：

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

2 回答 2

0

使用 newlib 在 printf 中崩溃的常见原因是不正确地设置了免费存储，特别是如果您使用的是 RTOS（即 FreeRTOS）。自 2019 年起，NXP（前身为飞思卡尔）将我的解决方案包含在 MCUXpresso 中。你可以在这里找到代码和详细解释：https ://github.com/DRNadler/FreeRTOS_helpers

于 2020-10-30T22:34:07.113 回答
0

当 ARM 应用程序在使用之前似乎可以正常工作时printf，最常见的问题是堆栈未对齐。在调用的函数的入口点放置一个断点printf并检查堆栈指针。如果指针不是双字对齐的，你就发现了你的问题。

于 2017-09-26T21:10:21.910 回答