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
Floating point calculations on 16 uC
Started by ●August 28, 2005
Reply by ●August 28, 20052005-08-28
On 28 Aug, in article <1125220291.973553.315000@g43g2000cwa.googlegroups.com> dbahlmann@gmail.com "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.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.>If anyone has had similar problems please let me know. Any advice when >using floating point calculations would be appreciated.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 <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
Reply by ●August 28, 20052005-08-28
"db" <dbahlmann@gmail.com> wrote in message news:1125220291.973553.315000@g43g2000cwa.googlegroups.com...> 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 >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
Reply by ●August 28, 20052005-08-28
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.
Reply by ●August 28, 20052005-08-28
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
Reply by ●August 28, 20052005-08-28
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[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
Reply by ●August 28, 20052005-08-28
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? ThanksIt could be a register modified by the ISR and not saved at the beginning and restored at the end.
Reply by ●August 28, 20052005-08-28
On 28 Aug 2005 02:11:32 -0700, "db" <dbahlmann@gmail.com> wrote:>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.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
Reply by ●August 28, 20052005-08-28
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? ThanksFirst 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
Reply by ●August 28, 20052005-08-28
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