#include <string.h> #include <stdio.h> #include <LPC214x.H> volatile int rc=0; volatile float A0 = 15.2, B0 = 0.152; int tst(const int iprivod,int id0, float iV0) { int iS0, iS2, it0, idx1, idt, iS_m=0x1234, it_m; iS_m = (int)(A0 * A0 /B0); //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ //Locals window show here 0x40000468 for iS_m //and 0x000005F0 if next line is commented iS_m = A0 * A0 ; it_m = A0/B0+0.5; id0 = iS_m; if(iV0 < 0.) { it0 = iV0/B0+0.5; } else { iS0 = iV0*iV0/(B0*2.); } if(id0 <= iS0) { if(iprivod > 0) { idx1 = 123; } else idt = 321;//it_m; return 0; } iS2 = (id0 + iS0); if(0x1235 > iS_m) { return iS_m; } return 2; } int main (void) { while(1) { rc= tst(1,1520, 0.); } }
However, one question from that thread does apply:
Does your code actually work?
ie, is it just a problem to get the debugger to display the "right" value, or is the code actually performing "incorrectly"?
Yes, just the same problem. And both cases involved float point.
Originally I want to find what is wrong with code with float point operatons that work fine from main() and work fine from interrupt routine in debuger, but hang up in real processor...Code does not used any side effects in C terms, but as I just found there is some relation between float point in interrupt and simple int (32 bit) arithmetics in main loop
"what is wrong with code with float point operatons that work fine from main() and work fine from interrupt routine in debuger, but hang up in real processor."
Do you mean debugger, or Simulator?
If it works in the Simulator, but not the real target (which is opposite to the other thread that you cited), that suggests that you have some hardware interaction that causes the problem.
This could be a bug or fault in your hardware, or could be something perfectly normal that your software doesn't handle correctly - eg, another interrupt occuring - which you haven't (properly) accounted for in your simulation.
Unless your processor has hardware floating point support, remember that all floating point operations will include Library calls - are you sure that your FP library is safe for use from interrupts? eg, is it reentrant? is it safe from atomicity issues?
"a bug or fault in your hardware"
In this context, by "bug" I mean a design flaw, and "fault" is something broken or incorrectly done.
You could, of course, have a combination of both...
I mean entity that run on Ctrl+F5 from mVison3.
I know that all floating point operations are Library calls , but I am sure that I use float point operation only in one place, so in general meaning(IBM PC's thread-safe general programming) this code is not re-entrant. Well, it may be not-interrupt-safe, then it should be mention somewere in docs, isn't it ?
I don't see or can't find this point in RV complier and library docs, the word "reentrancy" is mentioned only 3 times on page 5-9 without any regards to float point operations. May be I am wrong and missing some point ?
>Do you mean debugger, or Simulator? Well, I mean Simulator (debug with simulator) :-/
Well, now I have take screanshort
foto.rambler.ru/.../keil_bug.png
ft0 should be -0.5, but is shown as 2.001436 in locals window and as "0" in flying window (not shown), it0 should be = (int) -0.5,i.e 0 but is shown in locals as 1073747848 and as zero in flying window.
No interrups are called.