Floating point calculations on 16 uC

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.

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

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

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.

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.

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

[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

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

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

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
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

[snip...snip...]

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

--
Rich Webb   Norfolk, VA

DEADFACE seems to be popular here....

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

Two more are DEADC0DE (popular in OS-9) and CAFEBABE :) There is also

0xdeadbeef mailing list,

Vadim

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

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 ?