Jump to content
43oh

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.

Link to post
Share on other sites
  • Replies 249
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hi guys, I've finally hacked together a plugin for Eclipse that allows the msp430-gcc toolchain to be used from within Eclipse more easily. I must warn you that this is by no means finished, but I wa

It's seem that I finally succeeded in building a plugin for Eclipse, which contains compiled versions of GCC, GDB, and mspdebug, and also integrates these somewhat into Eclipse. Currently, I would str

I finally managed to get time to make a new release of the MSP430Eclipse plugin. As previously, it is available from http://eclipse.xpg.dk via the Eclipse "install new software" dialog. There are two

Posted Images

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

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?

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

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.

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?

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...