Miscalculations in seggers math.h with hardware float support enabled (FPU Hard, SES, math.h, asinf )

[mxhll]

Hello,

this is my second question in this forum, again regarding floats. (I hope its not something obvious like last time)

I`m getting very different results from asinf() in math.h provided by Segger, depending on the usage of the hardware FPU.
When ARM FP ABI Type is set to hardware, the function is not returning correct values.

Tested with:

    #include <math.h>
    
    uint8_t msg[50];

    float op;
    float result;

    for(int i=0; i<100; i++)
    {   
        op=i*0.01;
        result=asinf(op);

        sprintf(msg, "asinf of %f is %f", op, result);
        NRF_LOG_INFO("%s",msg);
    }

(+ some more standard includes like nrf_log and stdint etc)

This will output:

(ARM FP soft)

0> <info> app: asinf of 0.470000 is 0.489291
0> <info> app: asinf of 0.480000 is 0.500655
0> <info> app: asinf of 0.490000 is 0.512090
0> <info> app: asinf of 0.500000 is 0.523599
0> <info> app: asinf of 0.510000 is 0.535185
0> <info> app: asinf of 0.520000 is 0.546851
0> <info> app: asinf of 0.530000 is 0.558601
0> <info> app: asinf of 0.540000 is 0.570437
0> <info> app: asinf of 0.550000 is 0.582364
0> <info> app: asinf of 0.560000 is 0.594386
0> <info> app: asinf of 0.570000 is 0.606506

(ARM FP hard)

0> <info> app: asinf of 0.470000 is 0.489291
0> <info> app: asinf of 0.480000 is 0.500655
0> <info> app: asinf of 0.490000 is 0.512090
0> <info> app: asinf of 0.500000 is 0.523599
0> <info> app: asinf of 0.510000 is 1.058195
0> <info> app: asinf of 0.520000 is 1.069168
0> <info> app: asinf of 0.530000 is 1.080116
0> <info> app: asinf of 0.540000 is 1.091041
0> <info> app: asinf of 0.550000 is 1.101942
0> <info> app: asinf of 0.560000 is 1.112819
0> <info> app: asinf of 0.570000 is 1.123673

As you can see, asinf is not behaving as it should when using the hardware FP option. Is there something else I could have missed? Or should I ask Segger about it?
(nRF52840, SES 5.40 with included gcc compiler, also in 5.30)

Thanks in advance

Best Regards

[Vidar Berg]

Hello,

This looks strange. I have contacted Segger to see if they may have any suggestions as to what the problem might be. In the meantime, could you try to change the library optimization setting from 'fast' to 'small' in the project settings as shown below?

Best regards,

Vidar

[mxhll]

Hello Vidar,

thank you for your reply. Changing the library optimization to small did not improve the results.

Best Regards

Maximilian

[Vidar Berg]

Hello Maximilian,

I've not received feedback on my bug report yet. However, I think I found a way to make it work. The project uses the "Embedded studio"  library by default, but it seems to work if I change it to the Segger Runtime Library instead. Could you try the same to confirm?

Best regards,

Vidar

[mxhll]

Hello Vidar,

yes that seems to work for me aswell. I should measure the difference in performance when I have time. Still interested in Seggers response to this, maybe they can set the newer library as default if this bug persists.

I Imagine these functions are used a lot for IMUs and such, where the result might seem not entirely implausible, which makes it even more dangerous, I think. 

[Vidar Berg]

Hello Maximilian,

Thanks for confirming. I agree, this could be ugly bug . I will let you know as soon as I hear back from Segger on this. We might also consider changing the default library in our SDK examples.