嵌入式newlib-nano printf会导致硬件故障

我在两个目标（一个飞思卡尔，一个STM32和皮质M4）上编译“相同”代码。我使用--specs=nano.specs，并且我已经实现了_write函数作为空函数，并且这导致整个printf被GCC的-Wno-unused-function优化，即使STM32目标上的-O0（参见地图）。这很好，我想重现一下飞思卡尔的目标。嵌入式newlib-nano printf会导致硬件故障

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

到目前为止，我检查堆栈和堆不重叠和其他一些牵强拆卸。

为什么printf优化不在freescale目标上？什么可以导致库代码hardfault？为什么在进行组装一步一步的调试时可以吗？

编辑：

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

来源

2017-09-25 Julien

问题在其他地方是100％。 –

@ PeterJ_01这正是我需要解决这个问题的原因，因为我不知道其他地方会发生什么。您的评论可以更有用吗？ – Julien

不幸的是，如果没有实际的软件和硬件，DH很难进行诊断。我担心这是不可能的。使用我的水晶球 - 我赌矢量表的问题 - 没有正确初始化或某些向量拖欠DH。当你使用调试器中断时没有触发。当你运行程序“正常”的方式触发。也许定时器，也许systick，也许别的东西。你有两个不同的初创公司 - 需要自己看看。我知道我写了什么。如果是100％在别的地方。 –

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

来源

2017-09-26 21:10:21

堆栈指针对齐：在printf之前的0x1fff18e0和在hardfault中的0x1fff1830。链接器脚本是正确的'。 = ALIGN（4）;' – Julien

@Julien那不是你的问题，但它通常是'ALIGN（8）;'以确保堆栈位于双字边界上。 –

@D克鲁格，只是为了我的理解，为什么对齐（8）？是不是一个DWORD 4字节？ – Julien

嵌入式newlib-nano printf会导致硬件故障

回答

相关问题