Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by highfellow

  1. Thanks for the reply. I hadn't thought of doing that, but it would actually be a good solution in this case. Ideally I would rather work with a fully open source setup, but my colleagues are using the paid ccs and it would be good to maintain compatibility with them. (I work part time and move between home and office, and the company don't want to pay for another ccs license.)
  2. I'm trying to set up an eclipse / gcc / gdb / mspdebug based development environment to work on a custom msp430 based board that the company I work for produce. I have set up eclipse with the tools which come with ubuntu 15.04, and it's almost working apart from a weird bug in the debugger. When you watch a local variable in the main function, eclipse displays an incorrect value. This bug has been around for a while, as I've noticed it before (see this and the following page: http://forum.43oh.com/topic/1419-eclipse-plugin-for-mspdebug-and-msp430-gcc/page-3). The bug has been fixed in the
  3. I've just had a message from the author saying that it's not fixed yet. I can't really use that workaround because I'm working with contiki (an embedded OS), and the main() function is defined as part of the OS. I think I'm going to look at code composer for linux and see if that works any better.
  4. Maybe. I'm trying to find out if this has been fixed in the latest release. I'm using 20111205.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. Thanks. I'll have a go at some point using the toolchain in your package, but I'm leaving it now for a bit.
  11. 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?
  12. 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: 0x0000
  13. 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.
  14. OK, thanks. I've now got it to run the debugger, but it's still not picking up the right values for variables. This is the code I'm using: #include // stdbool.h, so we can use booleans and true/false as constants #include int main() { // The main function volatile unsigned int i = 0; /* Disable the watchdog. The watchdog is on by default on an * MSP430, if we do not disable it it will reset the CPU after * 32k cycles in the standard configuration. */ WDTCTL = WDTPW + WDTHOLD; // set P1.0 as output P1DIR = BIT0; // do forever: while (true) { i++; if (i == 0) { /* Flip the
  15. I've now got it to upload code with mspdebug (by building my own coreutils from the GNU site), but the debugging session won't start. This is the error: /bin/bash: /local/home/andy/workspace/Winky/Debug/Winky.elf: cannot execute binary file /bin/bash: /local/home/andy/workspace/Winky/Debug/Winky.elf: Success
  16. I'm actually using the precompiled eclipse indigo installation from the eclipse website. I spent a whole day trying to install msp430gcc myself a few weeks ago, and it felt like a waste of that work to switch ;-)
  17. I think I've worked out what's happening with the debugging problem. stdbuf is a program for setting the input/output streams for a program. This program is missing from my system - I think it's meant to be in coreutils, but it was brought in after ubuntu 10.04, so I don't have it. I should be able to find a way round this somehow.
  18. 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.
  19. @xpg: 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. I'm using ubuntu 10.04 with eclipse indigo.
  20. This plugin looks like it could be really useful. I've set it up as per the video, but on my system there are a couple of problems: - If I use #include to include the cpu-specific register defs, the compiler doesn't find the symbols. This is cured by using '#include ', but I don't want to do this long term because the project I'm working on uses io.h and it's not all my code. The compiler flag is set in the project properties - the full options are '-I/opt/msp430tools/msp430/include -I/opt/msp430tools/include -O0 -g -Wall -mmcu=msp430f2274 -std=gnu89' - the debugger isn't starting. I'm u
  • Create New...