Grant Edwards wrote:
On 2007-07-10, Bevan Weiss <[email protected]> wrote:

Since increased optimisation levels remedy the push/pop excess
I queried previously I've left them and continued on.  The
problem that I'm running into now is the microcontroller
resetting when it reaches the end of a called function.  I
believe this is due to the stack not being properly
initialised, does this seem justified?

It's more likely that the stack has overflowed or been
corrupted.
This seems a bit unlikely, as looking into it further, as soon as the program is in the main function (right after the prologue) the stack address is set to 490decimal (0x1ea hex) which is outside RAM. So the stack is wrong before my application code has a chance to do anything.

I can see that there is a collection of crtXXXX.o files
provided in mspgcc.  Is it likely that the source code for the
MSP430F2234 crt startup could be incorrect?

No.
Where abouts would I find the generating code to check on this one all the same?

Perhaps it's more likely that I've got a configuration option
wrong or similar.. any ideas would be greatly appreciated, I'm
starting to run quite a bit behind in this project.

Check to see if you're running out of stack space before you go
hunting for toolchain bugs.
The code isn't getting a chance to even use the stack. This is occurring when returning from the very first function call, the only thing that has been 'pushed' onto the stack is the return address so it seems unlikely that the stack is running out of RAM to use, or that it is being corrupted by program execution. The prologue does the expected setup of the stack pointer, but it just seems to use the totally incorrect value for a valid stack location.
The code section (pulled from the list file) is:
int main( void )
{
   e2e2:    31 40 ea 01     mov    #490,    r1    ;#0x01ea
   e2e6:    04 41           mov    r1,    r4    ;
...

I would think this would work if it instead read:
int main( void )
{
   e2e2:    31 40 ea 01     mov    #1023,    r1    ;#0x03FF
   e2e6:    04 41           mov    r1,    r4    ;
...

So I'm keen on tracing back where this comes from, I figure it starts with crtXXX.o and then goes back into the linker files.
I just want to make sure everything is correct with them..


Bevan

Reply via email to