Jump to content

highfellow

Members
  • Content Count

    21
  • Joined

  • Last visited

  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 most recent version of mspgcc from the old sourceforge site, but this is 2 years out of date now, and the development has moved to a project hosted by texas instruments: http://www.ti.com/tool/msp430-gcc-opensource . I would like to use the most recent version from ti if possible; I've tried compiling it and it builds OK, but I can't find a compatible libc and set of device specific header files which will work with it. When I try to use the libc that comes with ubuntu, it says it's incompatible. Also, when I pass the flag '-mmcu=msp430f5510', which used to work before, msp430-gcc throws an error. I've also noticed that the msp430 support appears to have been merged back into the upstream mspgcc (and presumably the other gnu tools), which is another way I've thought of going. So my question is, given all this, what's the best way to go to set up an up to date open source toolchain for the msp430? I could just compile the most recent version from the old sourceforge project, but would rather use something more up to date if that is possible.
  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: 0x000005FC 0003F7BE 00000000 00000000 00000000 00000000 00000000
  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 value of P1.0's output register when i * overflows to zero */ P1OUT ^= BIT0; } } } There's a breakpoint on 'i++;', but the value of i comes up in the watch window as 63422, and doesn't increment when I run to next breakpoint. Thanks for all your help so far by the way.
  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
×
×
  • Create New...