Eclipse plugin for mspdebug and msp430-gcc

[highfellow 0]

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.

[highfellow 0]

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

[highfellow 0]

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?

[xpg 127]

any ideas?

 

Not at this point, no. However, the current version of gdb for msp430 is an older one (see http://sourceforge.net/apps/mediawiki/m ... =Devel:git), so maybe this is causing issues ?

[highfellow 0]

Thanks. I'll have a go at some point using the toolchain in your package, but I'm leaving it now for a bit.

[xpg 127]

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 :-)

[highfellow 0]

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.

[highfellow 0]

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.

[highfellow 0]

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?

[Rickta59 589]

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

[highfellow 0]

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.

[Rickta59 589]

Have you see this? http://sourceforge.net/tracker/?func=detail&aid=3420924&group_id=42303&atid=432701

and this: http://sourceforge.net/projects/mspgcc/forums/forum/138167/topic/4952004

 

-rick

[highfellow 0]

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.

[Rickta59 589]

Maybe something like this:

 

#include 

void _main() {
// real code here
}

int main(void) {
   _main();
  return 0;
}

 

-rick

[highfellow 0]

Maybe. I'm trying to find out if this has been fixed in the latest release. I'm using 20111205.