embedded newlib-nano printf causes hardfault

2
votes

I compile the "same" code on 2 targets (one Freescale, one STM32 both with cortex M4). I use --specs=nano.specs and I have implemented the _write function as an empty function and this causes the whole printf to be optimized away by GCC's -Wno-unused-function even with -O0 on the STM32 target (seen in map). This is fine and I would like to reproduce that on Freescale target.

But on the Freescale target (with same compile flags) the printf causes hardfault. But if I go step by step with the debugger (assembly stepping) the printf goes through the library without hardfaulting. Simple breakpoint breakpoint sometimes not hit and run from any location in printf causes hardfault too (so it is unlikely that it is a peripheral issue).

So far I checked that stack and heap are not overlapping and some other far-fetched disassembly.

Why isn't the printf optimized away on freescale target ? What can cause the library code to hardfault ? Why is it OK when doing assembly step by step debug ?

EDIT:

  • Using arm-none-eabi-gcc 5.4.1 for both MCU with same libraries.
  • I do not want to remove printf, this is only a first step to be able to use them or not.
  • Vector table has default weak vectors for all ISR so it should be OK
  • Using the register dump it seems that the faulty instruction is at address 4 (reset vector) so the new question is now: why does the chip reset ?
2
cgccembeddedcortex-mnewlib
problem is 100% somewhere else. – 0___________
@PeterJ_01 this is exactly why I need to solve it because I don't know what could happen somewhere else. Could your comment be more usefull ? – Julien
Unfortunately DH are quite difficult to diagnose without the actual software and hardware. I afraid it is not possible remotely. Using my crystal ball - I bet problems with the vector table - not initialised properly or some vectors defaulted to DH. When you step with the debugger interrupt is not triggered. When you run program "the normal" way it triggers. Maybe timer, maybe systick, maybe something else. You hav different startups for both tragets - need to take a look yourself. I know what I write. If is 100% somewhere else. – 0___________
If all you want to do is to remove the printf, why not just define an empty function? – Shachar Shemesh
Are you compiling both with the same compiler instance? Same libraries? Which gcc version is that? – followed Monica to Codidact

2 Answers

0
votes

When ARM applications seem to work properly until printf is used, the most common problem is stack misalignment. Put a breakpoint at the entry point of the function that calls printf and inspect the stack pointer. If the pointer isn't double-word aligned, you've found your problem.

0
votes

The common reason for crashing in printf with newlib is incorrectly set up free storage, especially if you are using an RTOS (ie FreeRTOS). Since 2019 NXP (formerly Freescale) includes my solution in MCUXpresso. You can find code and detailed explanation here: https://github.com/DRNadler/FreeRTOS_helpers