Hard faults using sprintf() and float

Hard faults using sprintf() and float

[Jochen Strohbeck]

Hello,
I'm using newlib 2.4.0 as provided by the ASF / Atmel Studio
Installation. I'm on a SAME70 and my app is heavily using float32 and
therefore I'm interested in using printf and co. in my FreeRTOS / lwip
environment. Now it seems to me that there is a problem in memory
allocation stuff but I can't get deeper. Looks like sprintf with "%.3e"
format string results in a hard fault which I tracked down to the newlib
library. Any idea what I can do ?
Regards

In Hard Fault Handler
SCB->HFSR = 0x40000000
Forced Hard Fault
SCB->CFSR = 0x00008200
Bus fault:
r0 = 0x36353931
r1 = 0x00000000
r2 = 0x00000004
r3 = 0x2040b970
r12 = 0xfadffbfe
lr = 0x004461ff
pc = 0x00447128 <-- !!
psr = 0x81010000

_Balloc():
 447118: 6cc3 ldr r3, [r0, #76] ; 0x4c
:
 447126: b180 cbz r0, 44714a <_Balloc+0x32>
 447128: 6802 ldr r2, [r0, #0] <-- !!
 44712a: f843 2024 str.w r2, [r3, r4, lsl #2]
:
 44715e: 6044 str r4, [r0, #4]
 447160: 6086 str r6, [r0, #8]
 447162: e7e4 b.n 44712e <_Balloc+0x16>

Re: Hard faults using sprintf() and float

[Sebastian Huber]

Looks like you have a problem with misaligned loads. Check your MPU 
configuration.

On 24/03/17 09:34, Jochen Strohbeck wrote:
> Hello,
> I'm using newlib 2.4.0 as provided by the ASF / Atmel Studio
> Installation. I'm on a SAME70 and my app is heavily using float32 and
> therefore I'm interested in using printf and co. in my FreeRTOS / lwip
> environment. Now it seems to me that there is a problem in memory
> allocation stuff but I can't get deeper. Looks like sprintf with "%.3e"
> format string results in a hard fault which I tracked down to the newlib
> library. Any idea what I can do ?
> Regards
>
> In Hard Fault Handler
> SCB->HFSR = 0x40000000
> Forced Hard Fault
> SCB->CFSR = 0x00008200
> Bus fault:
> r0 = 0x36353931
> r1 = 0x00000000
> r2 = 0x00000004
> r3 = 0x2040b970
> r12 = 0xfadffbfe
> lr = 0x004461ff
> pc = 0x00447128 <-- !!
> psr = 0x81010000
>
> _Balloc():
>   447118: 6cc3 ldr r3, [r0, #76] ; 0x4c
> :
>   447126: b180 cbz r0, 44714a <_Balloc+0x32>
>   447128: 6802 ldr r2, [r0, #0] <-- !!
>   44712a: f843 2024 str.w r2, [r3, r4, lsl #2]
> :
>   44715e: 6044 str r4, [r0, #4]
>   447160: 6086 str r6, [r0, #8]
>   447162: e7e4 b.n 44712e <_Balloc+0x16>

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Hard faults using sprintf() and float

[Jochen Strohbeck]

Not sure what must be aligned and how. Could you please be more precise
? Here is a part of my linker script taken from Atmel's FreeRTOS demo:

    /* .bss section which is used for uninitialized data */
    .bss (NOLOAD) :
    {
        . = ALIGN(4);
        _sbss = . ;
        _szero = .;
        *(.bss .bss.*)
        *(COMMON)
        . = ALIGN(4);
        _ebss = . ;
        _ezero = .;
    } > ram

    /* stack section */
    .stack (NOLOAD):
    {
        . = ALIGN(8);
        _sstack = .;
        . = . + STACK_SIZE;
        . = ALIGN(8);
        _estack = .;
    } > ram

    /* heap section */
    .heap (NOLOAD):
    {
        . = ALIGN(8);
         _sheap = .;
        . = . + HEAP_SIZE;
        . = ALIGN(8);
        _eheap = .;
    } > ram

    . = ALIGN(4);
    _end = . ;
    _ram_end_ = ORIGIN(ram) + LENGTH(ram) -1 ;
}

I guess that printf/sprintf allocates dynamic memory. I provided
calloc_r(), alloc_r() etc in order to use the FreeRTOS memory allocation
but this doesn't seem to help out here. Therefore I would like to know
(a little) more about what must be provided in order to work newlib
smoothly with (Free)RTOS. Probably the info I found in the net is outdated.

BTW: Sometimes I get some weird formatted output as shown in the second
line of these three examples:

{"input":{"U":-1.955017e+01,"I":-4.877560e-04,"R":0.000000e+00},
{"input":{"U":-1.955017e+01,"I":-4.00    e-04,"R":0.000000e+00},

{"input":{"U":-1.956951e+01,"I":-4.856550e-04,"R":0.000000e+00},
{"input":{"U":-1.956951e+01,"I":-4.8  672e-04,"R":0.000000e+00},

{"input":{"U":-1.955017e+01,"I":-4.908266e-04,"R":0.000000e+00},
{"input":{"U":-3.00    e+01,"I":-4.959982e-04,"R":0.000000e+00},

Found this issue because the spaces between mantissa and exponent seem
to break the json parser in the python lib. Could this be related to a
probably memory misalignment or is this caused by something else ?

Regards,
Jochen



> Looks like you have a problem with misaligned loads. Check your MPU 
> configuration.

Re: Hard faults using sprintf() and float

[Richard Earnshaw (lists)]

On 24/03/17 11:48, Jochen Strohbeck wrote:
> Not sure what must be aligned and how. Could you please be more precise
> ? Here is a part of my linker script taken from Atmel's FreeRTOS demo:
> 
>     /* .bss section which is used for uninitialized data */
>     .bss (NOLOAD) :
>     {
>         . = ALIGN(4);
>         _sbss = . ;
>         _szero = .;
>         *(.bss .bss.*)
>         *(COMMON)
>         . = ALIGN(4);
>         _ebss = . ;
>         _ezero = .;
>     } > ram
> 
>     /* stack section */
>     .stack (NOLOAD):
>     {
>         . = ALIGN(8);
>         _sstack = .;
>         . = . + STACK_SIZE;
>         . = ALIGN(8);
>         _estack = .;
>     } > ram
> 
>     /* heap section */
>     .heap (NOLOAD):
>     {
>         . = ALIGN(8);
>          _sheap = .;
>         . = . + HEAP_SIZE;
>         . = ALIGN(8);
>         _eheap = .;
>     } > ram
> 
>     . = ALIGN(4);
>     _end = . ;
>     _ram_end_ = ORIGIN(ram) + LENGTH(ram) -1 ;
> }
> 
> I guess that printf/sprintf allocates dynamic memory. I provided
> calloc_r(), alloc_r() etc in order to use the FreeRTOS memory allocation
> but this doesn't seem to help out here. Therefore I would like to know
> (a little) more about what must be provided in order to work newlib
> smoothly with (Free)RTOS. Probably the info I found in the net is outdated.
> 
> BTW: Sometimes I get some weird formatted output as shown in the second
> line of these three examples:
> 
> {"input":{"U":-1.955017e+01,"I":-4.877560e-04,"R":0.000000e+00},
> {"input":{"U":-1.955017e+01,"I":-4.00    e-04,"R":0.000000e+00},
> 
> {"input":{"U":-1.956951e+01,"I":-4.856550e-04,"R":0.000000e+00},
> {"input":{"U":-1.956951e+01,"I":-4.8  672e-04,"R":0.000000e+00},
> 
> {"input":{"U":-1.955017e+01,"I":-4.908266e-04,"R":0.000000e+00},
> {"input":{"U":-3.00    e+01,"I":-4.959982e-04,"R":0.000000e+00},
> 
> Found this issue because the spaces between mantissa and exponent seem
> to break the json parser in the python lib. Could this be related to a
> probably memory misalignment or is this caused by something else ?
> 
> Regards,
> Jochen
> 
> 
> 
>> Looks like you have a problem with misaligned loads. Check your MPU 
>> configuration.
> 
> 

Your stack needs to be 8-byte aligned at all function boundaries.  The
compiler will maintain this invariant if start-up and interrupt code
handle the startup and interrupt entry code (most m-class cores will do
the latter automatically).

R.

Re: Hard faults using sprintf() and float

[Jochen Strohbeck]

>>> Looks like you have a problem with misaligned loads. Check your MPU
>>> configuration.

MPU is disabled in my application but this is also the case in FreeRTOS
demo code provided for SAME70. Must MPU be configured/enabled to avoid
the hard fault ?

> Your stack needs to be 8-byte aligned at all function boundaries.  The
> compiler will maintain this invariant if start-up and interrupt code
> handle the startup and interrupt entry code (most m-class cores will do
> the latter automatically).

I'm afraid that I don't quite understand you. I am using the linker
script from the FreeRTOS demo. Nevertheless I changed all ALIGN(4) to
(8) but the hard fault still occurs. According to the map file I seems
that the function boundaries in the newlib code are not 8 byte aligned.
Do I have to recompile the newlib stuff to achieve 8 byte alignment for
functions ?

Can I check if the provided newlib library is ready for (Free)RTOS
applications ?

Re: Hard faults using sprintf() and float

[Jochen Strohbeck]

The hard fault and strange formatted output does not happen if a
semaphore is used to protect sprintf().

Again, this problem seems only to happen if floats are printed and this
behaviour has been observed and reported by other users in the past and
I wonder what happens here. I have implemented malloc_r() which is using
FreeRTOS own heap4 pvPortMalloc() and is called by newlib's sprintf(),
printf(), puts() etc. So memory allocation seems not to be the real
problem here. Are there other functions to be implemented which are
called by sprintf() in order to protect it ?

In this article www.billgatliff.com/newlib.html the compile switch
REENTRANT_SYSCALLS_PROVIDED is mentioned. I defined
configUSE_NEWLIB_REENTRANT but get an ASSERT() due to a corrupted task
descriptor in FreeRTOS if sprintf() is not guarded by my semaphore.

I downloaded and compiled newlib on Windows but it seems that the lib is
built for Intel not ARM (makefile refers to gcc not arm-none-eabi-gcc).
Any switch that must be passed to configure ?


> Can I check if the provided newlib library is ready for (Free)RTOS
> applications ?

RE: Hard faults using sprintf() and float

[onkel.jack]

Just a hint:

I run into same problem for 2 reasons, but for a different operating system:
1. the malloc locks (using newlib malloc) did not work while I used multiple threads. this messed up the malloc chain.
2. I figured out, printf is quite hungry in respect of using stack. Depending on newlib config and version the stack usage of printf family counts up to around 1,5 Kb. So I would suggest as first check the size of your stack to have enough space to bear the need of printf. Especially in your case while printing float, this sounds shomehow familiar to me.

Good luck.
OJ



-----Original-Nachricht-----
Betreff: Re: Hard faults using sprintf() and float
Datum: 2017-04-03T15:20:14+0200
Von: "Jochen Strohbeck" <jochen@strohbeck.net>
An: "newlib@sourceware.org" <newlib@sourceware.org>

The hard fault and strange formatted output does not happen if a
semaphore is used to protect sprintf().

Again, this problem seems only to happen if floats are printed and this
behaviour has been observed and reported by other users in the past and
I wonder what happens here. I have implemented malloc_r() which is using
FreeRTOS own heap4 pvPortMalloc() and is called by newlib's sprintf(),
printf(), puts() etc. So memory allocation seems not to be the real
problem here. Are there other functions to be implemented which are
called by sprintf() in order to protect it ?

In this article www.billgatliff.com/newlib.html the compile switch
REENTRANT_SYSCALLS_PROVIDED is mentioned. I defined
configUSE_NEWLIB_REENTRANT but get an ASSERT() due to a corrupted task
descriptor in FreeRTOS if sprintf() is not guarded by my semaphore.

I downloaded and compiled newlib on Windows but it seems that the lib is
built for Intel not ARM (makefile refers to gcc not arm-none-eabi-gcc).
Any switch that must be passed to configure ?


> Can I check if the provided newlib library is ready for (Free)RTOS
> applications ?