Floating point calculations on 16 uC

Rich Webb wrote:
> On Sun, 28 Aug 2005 22:22:26 +0100 (BST),
> paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:
> 
> [snip...snip...]
> 
>>If you have space between bottom of stack allocation and the last variable
>>fill it with KNOWN values like hex 01,02,03.....
> 
> 
> Or maybe C0DE F00D, although some prefer using DEAD BEEF to FEED C0DE.
> Don't forget the C0FFEE. F00!   ;-)

DEADFACE seems to be popular here....

On 28 Aug 2005 07:32:34 -0700, "db" <dbahlmann@gmail.com> wrote:

>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

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

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

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

   Vadim

db wrote:
> 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

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.

In article <1125323242.505618.202750@g47g2000cwa.googlegroups.com>, 
cbarn24050@aol.com says...
> 
> db wrote:
> > 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
> 
> 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.

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

cbarn24 wrote:
>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.

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

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.

Hi

What version of the softune workbench are you using ?

"db" <dbahlmann@gmail.com> wrote in message
news:1125405033.861673.251120@z14g2000cwz.googlegroups.com...
> 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.
>