EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Problem with GNU ARM Toolchain and math functions

Started by Fausto Marzoli October 29, 2007
Alle 21:10, luned29 ottobre 2007, aaajbell ha scritto:

> Another problem I had with my LPC2103 was with the interrupt routines.
> I had to use the ISR_ENTRY and ISR_EXIT macros found by researching
> messages in this forum to get the return statement in an interrupt
> routine to work properly. Are you by chance using interrupts for your
> blink program?

Not in this case. I've tried also a FREErtos port and in that case there was
interrupts, too. But the interrupts seems to work.

Now I'm testing a very simple program that only calls one math function.

In this moment I'm compiling the last CVS newlib and gcc 4.2.2: I want to test
the last available code in order to see if there is some difference.

--
Fausto Marzoli - 8052.it - http://www.8052.it/

An Engineer's Guide to the LPC2100 Series

--- In l..., Fausto Marzoli wrote:
>
> Hi all!
>
> I have a problem that I can't fix with GNU ARM Toolchain and math
functions.
> Maybe someone has experimented floating point math function with GNU
ARM
> Toolchain and can help me...
>
> This is the problem: when using floating point arguments, some math
functions
> cause a program crash with "data abort" or "undefined instruction".
>
> I've done some tests with the newlib math functions with float
arguments, GNU
> arm toolchain and ARM7 NXP LPC2106 microcontroller:
> log works
> log10 works
> sqrt works
> tan Error (uncorrect result)
> cos Crash
> sin Crash
> pow Crash
>
> I've tried a lot of pre-compiled toolchains: YAGARTO, Ronetix,
CodeSourcery...
> I also compiled myself the toolchain (under linux): I tried a lot of
> different compiling options, always with the same results.
>
> I can't fix it. My test program is a simple test program that blinks
a led on
> a development board and in the led delay functions makes a dummy
math call
> (only to test the math call speed).
>
> If someone is interested in this argument, I can give you all the
info about
> compiling options or any other information you need.
>
> Anyone tried floating point math with GNU ARM Toolchain (arm-elf)
and newlib?
> Thank you,
>
> Fausto
>

Back on Oct 2d, there was a thread re: ARM7TDMI-S Conditional MOV
instruction not working. It was tossed back and forth because nobody
could believe that after millions of chips were sold and placed in
service that there could possibly be an error in the synthesis.

And there wasn't! It turned out to be a problem with a Segger J-Link
driver. Nothing at all to do with the ARM hardware.

I'm not saying that newlib works but, considering how many ports are
out there and how many developers are using it, I would be hesitant to
say there is a problem.

There are some fundamental floating point operations: add, subtract,
multiply and divide. From there, the other functions are built by
using various series expansions or other well known algorithms. They
all rely on the four fundamental operations to varying degrees. All
of the high level operations are written in C - how hard can it be to
verify the code?

My guess: stack problem. Or some other unrelated issue such as nested
interrupt routines.

A test program should take about 10 lines of code (not counting crt.s)
and it really couldn't be that hard to debug. So write a 10 line
program, bundle it up with crt.s, the makefile and linker script and
post it in the files section. Then everybody can hack away at it and
try to find the problem.

Something really simple:

#include
#include

float result;

int main(void)
{
result = sin(0.523598333);
printf("sin(30) = %f\n", result);
}

Compiled under Linux with:

cc -lm test.c -o test

and executed results in

sin(30) = 0.500000
The thing is, I just added

#include

and

printf("sin(30) = %f\n",sin(0.523598333));

to main.c of John Wren's EXCELLENT LPC2148 demo code (just ahead of
the task setup) and added -lm to the link flags and voila' The 2148
prints:

sin(30) = 0.500000

So, I am having a problem being convinced that there is a problem with
newlib.

Richard
Alle 18:26, marted30 ottobre 2007, rtstofer ha scritto:

> HOWEVER, the library still works for:
> pow(9.3, 3.3) = 1570.340134
> And, yes, it agrees with my calculator.
[...]
> There is a MUCH higher probability of a user problem.

And you are right!

It was a problem in my code. I've not yet exactly understood where the problem
was, but I can do math floating point operations now on ARM7 NXP LPC2106
microcontroller!

Thank you all very much for your help.

The problem must have been in the .ld linker file or in the crt0.s file,
because I tried using the boot.s and .ld files from the John Wren's LPC2148
demo code as you suggested, and it works!
--
Fausto Marzoli - 8052.it - http://www.8052.it/
Alle 14:42, luned5 novembre 2007, rtstofer ha scritto:

> That you have floating point operating is great but, if you have time,
> you should explore the differences in the files and find out EXACTLY
> where the problem occurred. It will probably lead to a greater
> understanding of the requirements of crt.s and the operation of 'ld'.

I agree: I'm going to do it!

Thank you, for now.

--
Fausto Marzoli - 8052.it - http://www.8052.it/

Memfault Beyond the Launch