[Dprglist] gcc ARM Cross Compiler help

[Steve Edwards]

I am not a compiler expert nor have I ever used *arm-none-eabi-gcc cross
compiler under linux* but i have WinDBG under Windows that cross compiles
with  \sysgcc\arm-eabi 6.2.0.

This may help.  i created two projects, both target same board STM32F401RE,
one enables HW FPU support and one uses Software FPU. you can compare the
makefiles to see several differences.  perhaps it will give you the info
you need.

-hth Steve

On Thu, Dec 22, 2016 at 5:16 PM, David Anderson <davida at smu.edu> wrote:

> For any who have worked with the STMicros STM32401RE board using the
> arm-none-eabi-gcc cross compiler under linux.  The LMX RTOS code is now
> running on the board and I can flash leds and write output to a UART.
>
> But there is a problem with the math generated by the compiler. Basically
> the math function "divide"  (/)  for single precision integers works, but
> crashes for double precision and for floats, doubles etc.
>
> Suspicious that it was something I'm doing, I stripped out everything,
> told the loader to give it a lot of stack space,  wrote this simple test,
> and turned off the -O2 optimizer:
>
> #include "main.h"
> #include "leds.h"
>
> /* ------------------------------------------------------------
> ----------------*/
> /* main */
> /* ------------------------------------------------------------
> ----------------*/
>
> int a,b,c;
> // long a,b,c;
> // long long a,b,c;
> // float  a,b,c;
> // double a,b,c;
>
> int main(void)
> {
>         /* initialize */
>         leds_init();
>         LED2_ON;
>
>         a = 65535;
>         b = 10;
>         c = a / b;
>
>         LED3_ON;
>         while (1) {};
>
>         /* should never get here */
>         return 0;
> }
>
> /* ------------------------------------------------------------ */
>
> The code turns on one LED, runs the math test, and turns on the second
> LED.   This works with ints and longs, but fails (2nd LED never lights)
> with long longs and floats and doubles.  I added casts for the appropriate
> constants but it didn't make any difference.
>
> I dumped the assembly code to see what was generated, and it appears that
> the ints and longs are divided by the machine instruction "sdiv" while the
> long longs call the function "__aeabi_ldivmod" and the floats call the
> function "__aeabi_fdiv".  But neither one of those calls appear to work.
>
> And why is it calling a function?  I thought this ARM Cortex-M4 processor
> included a hardware single precision FPU (FPv4-SP)?   Did I leave out some
> flag when building the compiler, newlib, or the application?  I think they
> were all built with "-mcpu=cortex-m4". Is something else required?  I tried
> "-mfpu=fpv4-sp" but the compiler said "no such thing" and offered
> fpv4-sp-d16 as the closest option.  It did not help.
>
> So... help!  Anyone seem this before?  Any of you compiler guru's have any
> suggestions?
>
> much thanks,
> dpa
>
>
>
>
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20161222/872a0eb9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STM32f401RE_WITH_HW_FPU_EmbeddedProject1.zip
Type: application/zip
Size: 10870 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20161222/872a0eb9/attachment-0002.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STM32f401RE_WITH_SW_FPU_EmbeddedProject1.zip
Type: application/zip
Size: 10833 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20161222/872a0eb9/attachment-0003.zip>