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.
>

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.

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

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

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.

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

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:
> 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 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!   ;-)

-- 
Rich Webb   Norfolk, VA

On 28 Aug, in article
     <1125239554.268511.307260@f14g2000cwb.googlegroups.com>
     dbahlmann@gmail.com "db" 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

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          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate