Hardfault from printf

[Greg Wood]

Posted on July 11, 2018 at 00:28

I have been struggling for several days now to track down a hard fault I am getting in one of my programs.  It seems to be related to printf (and similar) functions.

After running for a while I will get a hardfault from __vprintf_float_long_long().  Unfortunately that is where the stack trace stops.  The fault type varies, sometimes it doesn't even fault, it just gets stuck in __vprintf_float_long_long never to return.

Sometimes I get BFARVALID=1, and PRECISERR=1, and BFAR=0xFFFFFFFF.  Sometimes I get INVSTATE=1.

Presently, I have a fault on these lines:

F7FCF8B9 bl 0x08035B24 <__RAL_pre_padding>

9704 str r7, [sp, #16] 463A mov r2, r7 4641 mov r1, r8 2030 movs r0, #0x30 F7FCF8A5 bl 0x08035B08 <__RAL_print_padding> 1E63 subs r3, r4, #1 9305 str r3, [sp, #20] D40D bmi 0x080399E0 AF0D add r7, sp, #0x34 443C add r4, r7 F8DD8010 ldr.w r8, [sp, #16] F8141D01 ldrb r1, [r4, #-1]!  <--Faulted from here 4640 mov r0, r8 F7FCF87F bl 0x08035AD4 <__putc>

I have r1=0x20001780 and r4=0

I am using rowley crossworks V4.0 with their tasking library.  My processor is an STM32F446.  I have hardfloat enabled.

I have check my stacks and confirmed there is no overflow.  I have tried mutexing access to printf, replacing printf with vsnprintf, and many other things.  Is there something I can do to get more meaningful debug data?  Are there any know problems with gcc libraries that might explain what is going wrong?  Please help!

[AvaTar]

Posted on July 11, 2018 at 11:37

I have check my stacks and confirmed there is no overflow.

A stack overflow would have been my first guess.

... a hardfault from __vprintf_float_long_long() ...

Not sure what it means. A 'long double' ? I guess you have checked the library supports the format you want here.

F8141D01 ldrb r1, [r4, #-1]!  <--Faulted from here

What is R4 when it faults ?

[AvaTar]

Posted on July 11, 2018 at 11:45

Maybe you nonetheless have a stack problem ?

Wiht FPU, stackframes are larger, depending on the settings:

http://infocenter.arm.com/help/topic/com.arm.doc.dai0298a/DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf

 

[Greg Wood]

Posted on July 11, 2018 at 15:56

r4=0 when the fault occurs

I have been tracking the 'high water' mark on the stacks and they are all good.  Also, when faulted the psp points to the middle of a valid stack.

[AvaTar]

Posted on July 12, 2018 at 08:05

r4=0 when the fault occurs

Usually, there is no RAM around address 0. And (0 - 1) produces the fault address you see (BFAR=0xFFFFFFFF).

What is the C code line that produces the fault ?

Have you reviewed the project settings ?

I remember Crossworks use to have project properties for long integer/float printf support. Perhaps not the correct library ?

[Greg Wood]

Posted on July 12, 2018 at 15:37

I don't have the C code for this chunk.  It is part of a library.

I have check the project settings. I have long long and float printf enabled.

I got some code for another part of the library and built it as part of my project.  Now I'm never getting this fault.  I'm going to try with some optimization on today.

[AvaTar]

Posted on July 12, 2018 at 15:55

I don't have the C code for this chunk.  It is part of a library.

Rowley has it's own support forum, manned by their engineering staff. Perhaps you can post the issue there.

[Greg Wood]

Posted on July 13, 2018 at 01:28 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6w1&d=%2Fa%2F0X0000000byC%2FL6_FT4W5ONeiX0VJG50z.zyIUaTHyIRm_hs5HoIxf40&asPdf=false

[Tesla DeLorean]

Posted on July 13, 2018 at 02:39

It looks like it has encountered a NULL pointer, perhaps the routine and the parameters passed have a disagreement about how large something is.

Doesn't look to be an alignment issue, but most of the Cortex parts have various issues, especially 64-bit load/stores.

Rowley should be able to provide function source, or review on your behalf

Look at how much of the __vprintf_float_long_long() has been processed, ie format vs output. And how the format is derived from something you called in with.

[Greg Wood]

Posted on July 13, 2018 at 23:56

In this case I'm pretty confident the fault was not from vfprintf.  I wrapped all my printf calls and set a global whenever one is active.  The global was not set in the case of this fault.

What is the meaning of VECTPENDING=0x2F?