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.
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 | firstname.lastname@example.org
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
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.
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 | email@example.com
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
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.
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