F2 floating point call causes hard fault

[vneff]

Posted on June 24, 2014 at 22:52

I've started trying to use software floating point with the STM32F205.

I'm sure this has to do with the Yagarto/GCC toolchain, but I'm hoping someone can give me some ideas as to what might be going wrong. At this point, I'm simply trying to multiply to #s, ie. printf( ''got here 1'' ); float x = 2.0f; printf( ''got here 2'' ); float y; printf( ''got here 3'' ); y = x * 4.0f; printf( ''got here 4'' ); I get a hard fault before the ''got here 4'' line prints. The dump shows that PC and LR are pointing to locations in the above routine (not sure exactly where).  Never did get the debugging working. These are my compiler settings: -Wstrict-prototypes -Werror=return-type -Wformat -Wmissing-format-attribute -fno-common -std=gnu99 -mcpu=cortex-m3 -mfloat-abi=soft -mthumb and these are my linker settings -mcpu=cortex-m3  -mthumb -mfloat-abi=soft -msoft-float I increased my stack size 4 times normal. The map file shows that _arm_addsubsf3.o, _arm_muldivsf3.o, etc are included with the routines __subsf3, __addsf3, __mulsf3, __aeabi_fmul, __aeabi_fsub, __aeabi_fadd, etc. Though, for some reason, the double versions appear to be included as well. I know this should not be difficult, but I've run out of ideas. Any thoughts will be appreciated! Vance

[carl2399]

Posted on June 24, 2014 at 23:18

I've had floating point working using the STM32F405 (which is pin compatible) maths co-processor using Yagarto/GCC.

I have previously had problems with Yagarto/GCC when using C++ - the startup code crashed. My best guess (as I never found the root cause) is that one of the library files has some non-thumb code compiled in. You could generate an extended assembly listing of your code - which will include the assembly code for the maths functions. But I must say that it can be a bit tiresome going through the assembly language of the libraries. 

[vneff]

Posted on June 25, 2014 at 00:38

CJacobs,

Thanks for your response! My startup, etc. is good.  This is a large project with working USB, SD access, a few uarts, flash update and other stuff.  Everything has been working very well. The STM32F2xx does not have a hardware FPU ;-( I am using strictly C code, not C++. Any other thoughts! Vance

[Tesla DeLorean]

Posted on June 25, 2014 at 03:07

I'm not sure it needs specific options on the float side, but I'll put it on the bench and try the GNU/GCC builds I have.

[frankmeyer9]

Posted on June 25, 2014 at 09:12

I would start with verifying that the binary does not contain any FPU instructions, probably by disassembling it.

If I remember correctly, most gcc toolchains come with identically named math libraries, only in different folders for different ABIs. You might have picked up the wrong one for your project, despite of proper compile flags. Check your linker settings too, especially the lib and path-related one's (

-L

,

-l

).

[vneff]

Posted on June 25, 2014 at 14:22

The only library reference I make is:

-L\GNU_ARM_dev\yagarto-20121222\lib\gcc\arm-none-eabi\4.7.2\thumb There are no direct references to any Yagarto object libraries. The called fadd routine is located in: \GNU_ARM_dev\yagarto-20121222\lib\gcc\arm-none-eabi\4.7.2\thumb\libgcc.a(_arm_addsubsf3.o) I showed the compiler & linker switch settings in the initial post. Here is the assembly listing of the floating multiply call, The relative LR = 33 & PC = 38 when the fault occurred.:

322:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** 
323:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** 
324:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** log_printf( LPF_always, ''got here 2
'' );
1007 .loc 1 324 0
1008 0022 4FF0FF30 mov r0, #-1 @,
1009 0026 40F20001 movw r1, #:lower16:.LC1 @,
1010 002a C0F20001 movt r1, #:upper16:.LC1 @,
1011 002e FFF7FEFF bl log_printf @
325:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** x = x * 2.0f;
1012 .loc 1 325 0
1013 0032 3B69 ldr r3, [r7, #16] @ float @ tmp145, x
1014 0034 1846 mov r0, r3 @, tmp145
1015 0036 1946 mov r1, r3 @, tmp145
1016 0038 FFF7FEFF bl __aeabi_fadd @
1017 003c 0346 mov r3, r0 @ tmp146,
1018 003e 3B61 str r3, [r7, #16] @ float @ tmp146, x
326:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** if (!did_test_cos_routine)
1019 .loc 1 326 0
1020 0040 40F20003 movw r3, #:lower16:did_test_cos_routine.10342 @ tmp147,
1021 0044 C0F20003 movt r3, #:upper16:did_test_cos_routine.10342 @ tmp147,
1022 0048 1B88 ldrh r3, [r3, #0] @ did_test_cos_routine.0, did_test_cos_routine
1023 004a 002B cmp r3, #0 @ did_test_cos_routine.0,
1024 004c 3BD1 bne .L57 @,
327:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** {
328:C:\GNU_ARM_dev\Projects\TDP_eval_test\fence.c **** log_printf( LPF_always, ''got here 3
'' );
1025 .loc 1 328 0
1026 004e 4FF0FF30 mov r0, #-1 @,
1027 0052 40F20001 movw r1, #:lower16:.LC2 @,
1028 0056 C0F20001 movt r1, #:upper16:.LC2 @,
1029 005a FFF7FEFF bl log_printf @

the code is calling

__aeabi_fadd

, which I'm not sure if it is a hard or soft FP call. Interestingly, the compiler converted my x *2.0 to X + X. Vance

[frankmeyer9]

Posted on June 25, 2014 at 15:25

the code is calling

__aeabi_fadd

, which I'm not sure if it is a hard or soft FP call. That would actually be the interesting part. If you specified the wrong library, the code at __aeabi_fadd (pulled from this lib) contains FPU instructions. (Or ARM instruction for that matter, in contrast to THUMB).

[vneff]

Posted on June 25, 2014 at 17:49

According to this link:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.kui0097a/armcc_cjaidcjb.htm __aeabi_fadd is a software floating point routine.  Can't say for sure about thumb or not, except that the library is located in the thumb sub directory of the Yagarto libraries. Vance

[frankmeyer9]

Posted on June 26, 2014 at 10:50

According to this link:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.kui0097a/armcc_cjaidcjb.htm __aeabi_fadd is a software floating point routine. That doesn't say much. For the linker, __eabi_fadd is just a symbol he is looking for in all objects and libraries you specified in the call (say, the makefile). In this case, it happens to be the name of a function. And this symbol/function is present in every version of the

libm.a

you link in, but this libraries differ in ABI and instruction set. One version of the library is compiled with

float-abi=soft

, one with

float-abi=soft_fp

and one with

float-abi=hard

. The versions compiled with

soft_fp

and

hard

contain FPU instruction, which will surely hardfault on a Cortex M3. The linker does check the ABI (and warns/fails if you try to mix

soft_fp

with

hard

), but not if your platform actually supports FPU instructions at all. So, in your case, everything needs to be

float-abi=soft

.

[Tesla DeLorean]

Posted on June 26, 2014 at 18:24

int main(void)
{
int i;
float x = 1.234;
/*!< At this stage the microcontroller clock setting is already configured,
this is done through SystemInit() function which is called from startup
file (startup_stm32f2xx.s) before to branch to application main.
To reconfigure the default setting of SystemInit() function, refer to
system_stm32f2xx.c file
*/
USART3_Configuration(); // Setup USART for debugging on T2
USART3_OutString(''USART3 Float\r\n'');
for(i=0; i<10; i++)
{
printf(''%d %f\n'', i, x);
x = x * x;
}
while(1); /* Infinite loop */
}
USART3 Float
0 1.234000
1 1.522756
2 2.318785
3 5.376766
4 909609
5 8765503
6 6985000000
7 487907852000000
8 2380540793497171567575000000
9 inf

________________ Attachments : t2_usart_float_standalone_gnu.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1C1&d=%2Fa%2F0X0000000bkH%2FAvtxCAbEcIcvgemvzKL2Joyuz4ebq25X097VRNYjSF0&asPdf=false