Bevan Weiss wrote:
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..
I've just confirmed this.. despite the slight typo in the previous example.
I simply added in asm ( " mov #1024, r1 " );
recompiled and tested it out, it seems to work as originally expected.
This still leaves the question, where is the incorrect initial stack
value being obtained from.
Several things seem wrong with the MEMORY section of the linker files
for the MSP430F2234 devices (such as the vector location and length, as
well as the data length).
Everything else in the linker files seems reasonable, with the __stack
variable being PROVIDE'd as PROVIDE (__stack = 0x300) ;
This isn't optimum PROVIDE(__stack = 0x400); would be better, however it
should still work correctly.
Still begs the question where is the __stack value being neglected.
I've triple checked my makefile to ensure I'm not passing any
over-riding values in, and I'm not.
