-2

I am having problem in getting "vfprintf" provided by the NewLib library working on a multi-tasked environment based on the FreeRTOS running on a NXP K64 ARM Cortext-M4 processor.

The code is compiled using arm gcc compiler.

The FreeRTOS is configured to have the configUSE_NEWLIB_REENTRANT switch enabled.

I have provided the _write_r system call so eventually data will be passed on to the one of the MCU's UARTs.

A hard-fault exception is triggered in __sfvwrite_r when accessing the "fp->_p". In this case fp is the stderr which is assigned to xNewLib_reent.__sf[2] by default.

The default value of xNewLib_reent.__sf[2]._p pointer is NULL and is not allocated anywhere else.

Any advise on this regard is highly appreciated.

Update: In the hard fault ISR I extract PC from stack frame and by checking the assembly view in my debugger (i.e. Eclipse CDT stand alone debugger) I can see that it is crashing when dereferencing the _p pointer.

Max-Sbz
  • 11
  • 1

1 Answers1

1

Are you saying it crashes because the pointer you are de-referencing is NULL? If so, then why do you equate this to being a FreeRTOS problem? Is it because it works when you don't use FreeRTOS, but not when it does?

If the problem is not the NULL pointer then be aware than this family of library functions uses a lot of stack. Are you checking for stack overflow? http://www.freertos.org/Stacks-and-stack-overflow-checking.html

Richard
  • 3,081
  • 11
  • 9
  • Yes, in hard fault ISR I extract PC from stack and by checking the assembly view in my debugger (i.e. Eclipse CDT stand alone debugger) I can see that it is crashing when derefrencing _p pointer as mentioned before. In variable view I can confirm that _p is '0'. – Max-Sbz Mar 27 '17 at 22:51
  • I didn't mean that it is FreeRTOS problem. Have mentioned it just to provide more information about the environment that problem occurs. – Max-Sbz Mar 27 '17 at 22:52
  • Thanks for hint about stack size . I will check it again. – Max-Sbz Mar 27 '17 at 22:55