On 2011-06-28 23:17, Saira wrote:
> We are following the TI code for pulseoximeter
im[plementation which
> uses the function mul16. but the code is not compiled by IAR workbench
> if the function is used. moreover we have changed the code for
> MSP430F5437 but the configuration of ADC, UART and timer is kept the
> same and so is the signal processor and instead of an in-built DAC, DAC
> is implemented using PWM but the compiler keeps giving the stack pointer
> out of range error. the mul16 function is replaced by simple
> multiplication since this function is not mentioned anywhere in the user
> guide of MSP430F5437 or in the compiler help of the IAR workbench. Is
> the stack pinter overflow due to this change of function?
Hi!
Just to check that we are on the same page. Are you referring to the
SLAA274A zip-file provided by TI?
In this package, there are two source files. One is written in C and one
in assembler. The one written in assembler contains the function
"mul16", in other words, this is not something that is provided or
documented by the IAR tools.
One solution for you is to include the assembler file in your
application. Another solution would be to write this in C, like the
following (with the reservation that the routine provided by TI really
does what it is documented to do):
long mul16(short x, short y)
{
return ((long)x) * y;
}
If you do, the compiler will generate the appropriate code. In fact, if
you have a device with a hardware multiplier, this C code will be miles
faster than the assembler routine provided by the application note.
To answer your other question. No, I don't think that this is the reason
for you running out of stack. There are plenty of other ways to do this:
* Your stack is initially too small. Make sure that you allocate
enough space for it.
* You have recursive functions somewhere, and the recursion depth is
too deep or possibly infinite.
* Interrupts are not handled correctly.
Try to run it in a debugger and try to see what the stack contains when
it overflows.
-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
