Floating point calculations on 16 uC

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I'm doing floating point calculations on a Fujitsu MB90F474 16bit uC.
All float calculations are done in the main loop context. Sometimes the
result returns a garbage value. This seems to happen only when
interrupts are enabled. Note that there are no globals or shared data
involved.

If anyone has had similar problems please let me know. Any advice when
using floating point calculations would be appreciated.

Regards
Dieter


Re: Floating point calculations on 16 uC
On 28 Aug, in article

Quoted text here. Click to load it

Look at your map file to see where the last local variables are before
the bottom of your stack. It sounds like the stack is overwriting the
variables as your stack is not large enough. If possible write some
known values after the last variables (like hex 01, 02, 03, 04, 05, 06...)
into the stack area. Then see what ones are still there when interupts
are enabled.

I suspect that local variables for your floating point routines are what
are being corrupted.

Quoted text here. Click to load it

I don't think it is floating point related, but stack related due to too
small a stack size for your application.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Floating point calculations on 16 uC
I do have a stack routine checking the stack usage, it does not report
any problem. Will check the checking routine to make sure it reports
correctly. Thanks.


Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

Either:

1: The interrupt routine is corrupting data, which happens to be where the
floating point math routines store values.

2: Your stack is too small.  Including floating point values in your main
loop will increase stack usage somewhat.

3: Your floating point library is not re-entrant and you are using float
variables within the ISR.


Most likely it's number 2.  Should not be number 3 as it's not a good idea
to use float values in an ISR anyway.

Regards,
Richard.


http://www.FreeRTOS.org




Re: Floating point calculations on 16 uC
It's not 1 or 3. Number 2 could be possible but the float routines is
not very big and I have about 6KB stack allocated. I have decreased
stack size to 4KB to see if the problem gets worse but it stays the
same. Any other possibilities? Thanks


Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

[Please quote relevant portions of context when replying. Thanks.]

One possibility is that (stack allocated) is not necessarily equal to
(stack actually used).

--
Rich Webb   Norfolk, VA

Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

It could be a register modified by the ISR and not
saved at the beginning and restored at the end.


Re: Floating point calculations on 16 uC
On 28 Aug, in article

Quoted text here. Click to load it

First as other have said quote the article you are answering.

Second HOW do you know that reducing the stack size means the
problem "stays the same"?

If memory map is as a guide

Address Stack top
                6KB
        Space           0 to n bytes
        Last variable

When reducing the stack size may just make this

Address Stack top               (address same as when stack was 6KB)
                4KB
        Space           2K to 2k+n bytes
        Last variable

If when running with 6KB stack (for whatever processor/compiler compilation
you are using), the stack actually used is 6K + m bytes, if m is larger than
the space between your stack ALLOCATION and the last variable byte, then it
WILL overwrite the variable. This will happen NO matter what allocation size
you reduce it to.

If you have space between bottom of stack allocation and the last variable
fill it with KNOWN values like hex 01,02,03..... Check this has loaded
correctly before starting. When the process gives a garbage value check
these locations again, if different your stack actually has grown larger
than predicted.

There may be other problems but without details from a MAP file showing
what there is in address ranges from the last variable to where the stack
is and proof that you have performed some test of your own, (not some
stack routine that may be flawed).

What happens if you remove some variables or a module, to leave a larger
space below the stack?

What compiler, processor and other details would be helpful. It may be other
issues to do with the interupt routine itself, but more likely stack usage
is larger than you think it is.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Floating point calculations on 16 uC
On Sun, 28 Aug 2005 22:22:26 +0100 (BST),

[snip...snip...]
Quoted text here. Click to load it

Or maybe C0DE F00D, although some prefer using DEAD BEEF to FEED C0DE.
Don't forget the C0FFEE. F00!   ;-)

--
Rich Webb   Norfolk, VA

Re: Floating point calculations on 16 uC
Quoted text here. Click to load it

DEADFACE seems to be popular here....


Re: Floating point calculations on 16 uC
Quoted text here. Click to load it

Two more are DEADC0DE (popular in OS-9) and CAFEBABE :)  There is also
0xdeadbeef mailing list, http://www.petting-zoo.net/~deadbeef /

   Vadim

Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

You've assured us that changes in stack size do not appear to impact
the behavior.  My own experience in areas like this are that they
occur when there is static variables involved in the floating point
routines and that the interrupt routines are modifying them in some
way.  If you pre-empt an in-progress floating point operation that
depends on some temporary static region for its work and if the code
that pre-empts it also calls some function that re-uses this static
area, that's all that is needed.

It DOES NOT have to be the case that your interrupt procedures use the
floating point, though that is certainly a common source of problems
in this case.  It may only be that some other library code also shares
this temporary static region for any purpose at all -- the only
requirement is that it does mess up the in-progress static areas being
used by the particular floating point code.  That could just be a
common buffer used for many other purposes, such as atof() or gcvt()
or even something you might not expect at all.

I'd be spending some time looking over the floating point source code
-- which should be provided.

Jon

Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

I have never seen that processor before, but here are some guesses.

Since all the others have posted the most likely explanations, look at
the library routine sources (assuming written in assembler) for using
the stack are without actually pushing the value into the stack, but
using offsets below the stack pointer (assuming the stack grows
downwards).

In which language is the interrupt service routine (ISR) written ? If
in some high level language, are you sure that the language subsystem
support interrupt service routines ?

If written in assembler, are you sure that every register used by the
ISR is really saved ? Pay especially attention to instruction with
side effects, such as implicitly modifying an other register, which is
not saved.

Paul
  

Re: Floating point calculations on 16 uC

Quoted text here. Click to load it

You dont say what kind of garbage your getting. Stack overruns are easy
to detect as it will trash your fixed variables starting from the
highest 1 (check your map file). Sometimes you can have problems with
far/near pointers. Compile useing the large model and see if your
problem dissapears. If all else fails disable each interrupt
individualy.


Re: Floating point calculations on 16 uC
snipped-for-privacy@aol.com says...
Quoted text here. Click to load it

There is one rather ugly variant of stack overflow that I ran across many
moons ago (I've forgotten which compiler).  That particular compiler used
space on the stack BEYOND the current stack pointer for floating point
storage, the net result of cource being that any interrupt was just about
assured of corrupting a floating point operation if it occurred during
the time that floating point calculation were down.

Thankfully I wasn't contemplating any floating point being used but
reading that ensured I din't even try.

Lesson learned, make sure you read your compiler manual.  All of your
compiler manual.

If your compiler manual has a section of the floating point
implementation make sure you read it and understand what it's using for
storage.  These sections often have notes on interactions with interrupts
and task switching.

Robert

Re: Floating point calculations on 16 uC
Quoted text here. Click to load it

I don't think it's stack overflow. I have a "stack used" funtion and it
reports almost 3KB not used. My memory model is currently medium. Can
you explain in more detail why this will effect the floating point
variables. Note that this only happens intermittently. Usually the
results are correct. Thanks


Re: Floating point calculations on 16 uC
to all:

It turns out to be a register that was not pushed in one of the
assembler routines used by an ISR. This register was also used by the
float lib. Thanks for everyones feedback. db.


Re: Floating point calculations on 16 uC
Hi

What version of the softune workbench are you using ?

Quoted text here. Click to load it



Site Timeline