Jump to content
xpg

Eclipse plugin for mspdebug and msp430-gcc

Recommended Posts

The io.h fix would be good for me because the main thing I'm working on is trying to get contiki 2.5 working with the ez430, and contiki uses all over the place.

 

Though if necessary I could hack io.h to force it to include the right header file, and leave the contiki includes as they are.

 

I've just tested this and it doesn't work, which is pretty odd. If I set the include in my main.c to , the scanner picks up the symbols correctly, but with it doesn't work. This happens even when I've changed the io.h in msp430-gcc to always include that header file regardless of the compiler flags.

Share this post


Link to post
Share on other sites

I think I've worked out what's happening with the debugger not showing the right watch value for 'i'. The code is running OK - the light flashes - but the place eclipse looks for the variable on the stack is out by 2 bytes. If I watch the memory near the stack pointer, I can see 4 bytes at 0x05FC. The first 2 bytes increment when you step the program through 'i++', and the second 2 bytes have the value 'F7BE'. F7BE is 63422 in decimal, which is the value eclipse is reporting for the variable. The stack pointer is shown as 0x05FE.

 

The memory dump around the stack pointer looks like:

0x000005FC 0003F7BE 00000000 00000000 00000000 00000000 00000000

Share this post


Link to post
Share on other sites

It looks like this is caused by conflicting endianness / address block size between eclipse and gdb. Setting 'set remotaaddresssize 64' in the gdb startup helps, but doesn't quite solve it. The variable is shown in the right place in the memory view, but the watch expression is reading the wrong word.

 

any ideas?

Share this post


Link to post
Share on other sites
Thanks. I'll have a go at some point using the toolchain in your package, but I'm leaving it now for a bit.

I'm quite sure that the prebuild toolchain has the same problem.

When I get some spare time on my hands, I'll try to see if I can solve this issue. Thanks for your research into this, it surely makes it easier for whoever ends up solving it :-)

Share this post


Link to post
Share on other sites
Thanks. I'll have a go at some point using the toolchain in your package, but I'm leaving it now for a bit.

I'm quite sure that the prebuild toolchain has the same problem.

When I get some spare time on my hands, I'll try to see if I can solve this issue. Thanks for your research into this, it surely makes it easier for whoever ends up solving it :-)

 

I was having the same issue using the standard CDT debug configuration as well, so it's not necessarily your code that's at fault.

Share this post


Link to post
Share on other sites

At the moment my gdb startup commands look like:

 

set remoteaddresssize 16
set remotetimeout 999999
set endian little
monitor endian little

 

It's still not working, so any help would be great.

Share this post


Link to post
Share on other sites

I've been looking into this a bit more and it looks like the memory dump and register values reported by eclipse are right (I've checked this against the values from mspdebug in command line mode), but for some reason it's looking at the wrong stack location for the local variable 'i'. This only happens when 'i' is a local variable on the stack, not when I make it a global variable.

 

Does anyone know of any settings in Eclipse I might have missed, which could affect this?

Share this post


Link to post
Share on other sites

Is 'i' a stack variable in main()? I seem to recall a bug and a partial fix in gcc. The partial fix meaning stack variables in main weren't fixed. Try calling a function from main that never returns.

 

-rick

Share this post


Link to post
Share on other sites

It is a local variable in main. The disassembly of the code looks right though - it's loading the value from memory, incrementing it, then saving it again, and the memory address in the code is the same as the stack pointer, which I think is right as there's only one local variable. The problem is eclipse is looking for the variable value 2 bytes below the stack pointer.

Share this post


Link to post
Share on other sites

I have now! Thanks - this makes me feel a bit better now I know it's a known bug.

 

The people at work are saying they want it all working in code composer eventually, so I might just switch to that. Or else see if I can find a fix or workaround for the gcc bug.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×