double and XTI_IRQHandler

ewitt · ‎2006-09-13

Posted on September 13, 2006 at 12:49

pete3 · ‎2006-09-11

Posted on September 11, 2006 at 09:18

What does the mapfile say about the location of these variables? Does declaring them as static or volatile make any difference? This should force the linker to keep them in the same memory location (although with such a small program it should anyway).

Other than this the only problem I can see is the re-entrance problem from earlier. Do the external interrupts fire very often?

ewitt · ‎2006-09-11

Posted on September 11, 2006 at 09:26

Defining them as static or volatile does not help either ... (I have already tested that).

As i said before, the XTI do not fire very often. approx 1time/sec.

pete3 · ‎2006-09-11

Posted on September 11, 2006 at 09:58

Ah, sorry, I thought that was the timer.

If the debugger is reporting it cannot find the location you may need to tell the linker to add debug information to the files. What does the map file say? You should be able to call up the contents of the memory location of your variable with this information and make sure it is correct (although it will be in IEEE 754 format).

Alternatively you could write your own UART method to output the values you need although beware that interpreting IEEE 754 may take a couple of days!

ewitt · ‎2006-09-11

Posted on September 11, 2006 at 10:52

I already know that the content of the double variables are correct. I checked it with multiple if-Statements. - No need to check the memory directly. Nevertheless I have to use sprintf and printf repectivly. But I am going to check the linker options...

ewitt · ‎2006-09-11

Posted on September 11, 2006 at 14:50

By trying to make a workaround of the problem with sprintf and printf I noticed that also mathematical functions returning double (like floor, abs, asin, etc.) do not operate correctly when executed from a interruptserviceroutine. The returned double values are incorrect (bogus). Doing the mathematical functions from main do work... I do not get the problem ...

pete3 · ‎2006-09-12

Posted on September 12, 2006 at 09:54

The only difference between the operating modes I can think of offhand is that during an interrupt the chip will be using the INT mode instead of USER or SYSTEM. I don't know what effect this will have on the std libraries.

You have previously said that the XTI fires every sec or so. How often does the timer fire? Do the two interrupts fire at the same or nearly the same time?

ewitt · ‎2006-09-12

Posted on September 12, 2006 at 10:41

TIMER1 Fires approx 1time/sec. and enables a ADC sampling. The ADC sampling takes approx. 40Âµ, then XTI (after end of conversion) is fired.

pete3 · ‎2006-09-12

Posted on September 12, 2006 at 11:19

Well, I have no idea of the cause, but you could put the chip into a low-power mode before enabling the timer to wake it. When the chip wakes, you could perform all the tasks in your code.

Not exactly satisfactory though, is it?

kleshov · ‎2006-09-12

Posted on September 12, 2006 at 11:30

Just a shot in the dark, but could it be a stack alignment issue? I think I heard somewhere that in order for double-precision floating point to work, some runtime libraries require stack alignment on 8-byte boundary to be activated.

ewitt · ‎2006-09-13

Posted on September 13, 2006 at 12:49

the problem also use to happen with float variables...

In order to narrow down the problem i wrote 2 functions. :

Code:

void isinc(int number, char* buffer) { float sin; sin=asin(((float) number)/10); ftoa(sin,4,buffer); //converts float to char* } void fsinc(float number, char* buffer) { float sin; sin=asin(number); ftoa(sin,4,buffer); //converts float to char* }

The only difference is that the first accept int and the second float values. If i call both functions from a ISR e.g.

Code:

void T0TIMI_IRQHandler(void) { char cisin[8], cfsin[8]; isinc(3, cisin); fsinc(0.3, cfsin); }

Now cfsin and cisin are supposed to have the same value right? But they don't isinc works fine and fsinc returns nothing.

If i set an breakpoint into both functions then I can see the right values in function isinc(), but if the debugger steps into fsinc(), he is not able to trace any float variable.

I do not get whats going wrong!

[ This message was edited by: ewitt on 13-09-2006 16:44 ]

[ This message was edited by: ewitt on 13-09-2006 16:48 ]

[ This message was edited by: ewitt on 13-09-2006 16:49 ]

________________

Attachments :

floattrouble.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtA8&d=%2Fa%2F0X0000000aJl%2Fz2NBu8gf0IEhFVpgCQsUJ7Upze2Pvbd9V6DFE37hGRc&asPdf=false