Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Ok, I'm a bit confused (which is not all that unusual). I thought that the Educational Booster Pack code originally targeted at the 430 had been ported to Stellaris. I downloaded a library from here: http://embeddedcomputing.weebly.com/libraries.html that says "Educational BoosterPack Library for LaunchPad MSP430 and Stellaris with Energia". But looking at the source code for the POT example distributed with the library, I see: #if defined(__MSP430G2553__) || defined(__MSP430G2452__) // LaunchPad specific #else // error #error Platform not defined #endif And indeed commenting out the #ifdef results in compile errors within the library, most of which appear to be that the code references pins with the Pn_m style references which clearly won't fly unmodified on Stellaris. So is there another version of the Educational Booster Pack library for which I should be looking? Thanks for any help you can provide.
  2. Just listened to a Texas Instruments Webinar on the LaunchPad product line. They were very complementary towards Energia, touted the release of Energia for the Stellaris/ARM LaunchPad and even demo'ed Energia with the new "Educational" Booster Pack. Basically, they seemed to position Energia as an easy entry point for the LaunchPad environment, and although they often made reference to CCS as their "professional" IDE, between the demo and the questions, much of the software focus seemed on Energia. They also spoke highly of 43oh in general. All in all, I'd say this is a very positive development and I was rather amazed that TI was so positive about third party software and the 'Net community in general.
  3. Thanks! Eagerly awaiting that next release!
  4. Hopefully support for the FRAM boards (I have a couple of MSP-EXP430FR5739) will make it into an Energia binary release soon. Sounds from the discussion in the links that folks have patched relevant sections and gotten it to work, but my experience with attempting to build Energia from source have been uniformly flaky. I'd love to use Energia on those boards, however. The FRAM platform seems ideal for a small data logger.
  5. The binary version works just fine on my (non-VM) Ubuntu system. Alternated between co piling and uploading Blink and AnalogInputSerialOutput, and it worked great. This used to hose up on the earlier version, per all the weirdness in the thread above. Thanks very much.
  6. Interspersed C and Asm listing from Blink compile looks quite sane. I'll try on non-VM hardware tonight, and let you know what happens. As always, thanks so much for your excellent support and patience.
  7. Thanks. I made a local symlink but the method in your post above is probably cleaner. In any event, linking the newer libgmp to the 3.0 version works to get compiling to work. My attempt to download the sketch hung, but I believe that is because of the funky virualization of the relevant USB device by VirtualBox. Is there anything I can look at in the generated elf file to see if the compilation looks OK? I will give this a try directly on the Linux H/W this evening as well.
  8. Update: Forging the following symlink gets a compile of blink to complete in the env decribed above: export LD_LIBRARY_PATH=`pwd` ln -s /usr/lib/libgmp.so.10 `pwd`/libgmp.so.3 Not sure if I will be able to upload the generated program in the VM however.
  9. Gave the binary distro linked above in this thread a quick trial on a VirtuaBox VM at my office. (Only have access to VirtualBox VM here. My machine at home is a bare-metal, non-virtualized install). Fails compile looking for libgmp.so.3. My system is Ubuntu 11.10. Here's the message get from the attempted compile: /home/jerry/Downloads/energia-0101E0008/hardware/tools/msp430/bin/../libexec/gcc/msp430/4.6.3/cc1plus: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory jerry@jerry-VirtualBox:~/Downloads/energia-0101E0008$ find / -name "libgmp*" 2>/dev/null /usr/lib/libgmp.so.10 /usr/lib/libgmp.so.10.0.1 /usr/lib/i386-linux-gnu/openssl-1.0.0/engines/libgmp.so /usr/share/doc/libgmp10 /var/lib/dpkg/info/libgmp10.shlibs /var/lib/dpkg/info/libgmp10.postinst /var/lib/dpkg/info/libgmp10.md5sums /var/lib/dpkg/info/libgmp10.list /var/lib/dpkg/info/libgmp10.postrm jerry@jerry-VirtualBox:~/Downloads/energia-0101E0008$ echo $LD_LIBRARY_PATH jerry@jerry-VirtualBox:~/Downloads/energia-0101E0008$ find . -name "*.so*" 2>/dev/null | more ./hardware/tools/msp430/libexec/gcc/msp430/4.6.3/liblto_plugin.so ./hardware/tools/msp430/libexec/gcc/msp430/4.6.3/liblto_plugin.so.0.0.0 ./hardware/tools/msp430/libexec/gcc/msp430/4.6.3/liblto_plugin.so.0 ./lib/librxtxSerial.so ./lib/librxtxSerial64.so jerry@jerry-VirtualBox:~/Downloads/energia-0101E0008$ Should I forge a symlink from libgmp.so.3 to libgmp.so.10, for instance? Any suggestions welcomed.
  10. So sorry, I missed your last reply re binary version. Great! I'm on that tomorrow, for sure. Thanks to all for your help in this forum. This is a terrific group. Jerry
  11. Thanks. I think I'll wait and try the binary distribution. But I really appreciate all the help. Folks on this forum are very responsive, and that's wonderful.
  12. I've also experienced the serial port becoming unavailable (or unusable) after using the Serial Monitor option in Energia on Window 7. Selecting another COM port and then re-selecting the "real" one seems to work so far in my limited experimentation. In other words, your board might be say, COM8, so switch to COM1, then back to COM8 and that may clear things up for the next run. Hope this helps.
  13. Ok, I'm back at attempting to get Energia compiling and loading reliably on my Linux platform. I really appreciate the help I've gotten from folks here so far, but I'm quite stuck at the moment. I build mspdebug from the latest source here: http://sourceforge.net/projects/mspdebug/files/ Had to install libusb-dev, but compile was fine. Just for good measure, I had applied the patch for flaky /dev/ACM0 from here: https://github.com/energia/Energia/wiki ... munication Fired up Energia, and successfully compiled and downloaded the Blink sketch into a brand new 430 board, chip is a 2553. Blink sketch ran fine. Then I tried to compile and load the AnalogInSerialOut sketch. Compiled OK, and appeared to upload. But no joy on the Serial Monitor. Went back to the Blink sketch and now while that will compile and upload, it won't run. Went into /tmp, found the elf and attempted to manually load and run it using mspdebug, like this: Result is shown below: mspdebug rf2500 (mspdebug) erase Erasing... (mspdebug) load Blink.cpp.elf Writing 376 bytes to c000 [section]... Writing 32 bytes to ffe0 [section]... Writing 8 bytes to 0204 [section]... Writing 8 bytes to 020c [section]... Writing 8 bytes to 0214 [section]... Writing 8 bytes to 021c [section]... Writing 16 bytes to 0224 [section]... Writing 21 bytes to 0234 [section]... Done, 477 bytes written (mspdebug) run Running. Press Ctrl+C to interrupt... ( PC: 0c000) ( R4: 013bd) ( R8: 036df) (R12: 0ed7f) ( SP: 0c11d) ( R5: 0c7be) ( R9: 05ef5) (R13: 0e7ec) ( SR: 00000) ( R6: 000be) (R10: 000ce) (R14: 00001) ( R3: 00000) ( R7: 0447f) (R11: 000d0) (R15: 09838) 0xc000: 0c000: b0 12 0c c1 CALL #0xc10c 0c004: b0 12 12 c0 CALL #0xc012 0c008: b0 12 1e c0 CALL #0xc01e 0c00c: fd 3f JMP 0xc008 0c00e: 30 40 (mspdebug) This is the same problem I had before (after kind help in this forum got me past some earlier problems). The generated code acts as if it has a breakpoint set at the very beginning. Each run command instantly dumps the message shown, which seems to be just before the setup method. Per another suggestion on this thread, I'm going to see what I can figure out with objdump, In the meantime this is really puzzling me, and I appreciate any and all suggestions about how to proceed.
  14. Yes, chip is a mps430g2553. Ordered a tube of them the other day to replace what was originally in my older 430 boards. Tried a couple of boards as well, same result. Just tried Energia under OS X and Blink and Button sketches work fine, compile, download and run. Still struggling with Serial Monitor there, but that likely isn't related. So I'm thinking that something's up with mspdebug on the Linux platform? Thanks for the quick response.
  15. Many thanks for your help so far. Some progress, but more weirdness. For the Blink example, I am able to compile it under the Energia UI, and then load the program "manually" using mspdebug to load the generated ELF. (Per your suggestion) This gets around the apparent failure to erase and load when spawned from Energia. This works, but seems intermittent, in the sense that sometimes I load the Blink.cpp.elf file (erasing the chip first) using mspdebug and when I issue the run command it does run and the LED blinks. Other times when I load the program (or any other sketch in the Basics section) running the program almost looks as if it hits an immediate breakpoint, like this: Trying to open interface 1 on 005 rf2500: warning: can't detach kernel driver: No data available Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Set Vcc: 3000 mV fet: FET returned error code 4 (Could not find device (or device not supported)) fet: command C_IDENT1 failed fet: identify failed Trying again... Initializing FET... FET protocol version is 30066536 Configured for Spy-Bi-Wire Sending reset... Set Vcc: 3000 mV Device ID: 0x2553 Device: MSP430G2553 Code memory starts at 0xc000 Number of breakpoints: 1 Available commands: = delbreak gdb load opt reset simio alias dis help locka prog run step break erase hexout md read set sym cgraph exit isearch mw regs setbreak Available options: color gdb_loop iradix fet_block_size gdbc_xfer_size quiet Type "help " for more information. Press Ctrl+D to quit. (mspdebug) erase Erasing... (mspdebug) prog Blink.cpp.elf Erasing... Programming... Writing 376 bytes to c000... Writing 32 bytes to ffe0... Writing 69 bytes to 0204... (mspdebug) run Running. Press Ctrl+C to interrupt... ( PC: 0c000) ( R4: 065dd) ( R8: 0ffff) (R12: 0804f) ( SP: 0c11d) ( R5: 09bfe) ( R9: 0000e) (R13: 097fd) ( SR: 00000) ( R6: 0002e) (R10: 0c3fb) (R14: 00000) ( R3: 00000) ( R7: 0feff) (R11: 0b789) (R15: 0ad64) main: 0c000: b0 12 0c c1 CALL #init 0c004: b0 12 12 c0 CALL #setup 0c008: b0 12 1e c0 CALL #loop 0c00c: fd 3f JMP main+0x8 0c00e: 30 40 (mspdebug) The program only runs for a split-second, then the register dump appears. Subsequent run commands return almost immediately to this point. Pretty clearly this is the start of the program but why isn't it looping? I am going to investigate a newer version of mspdebug, but I don't remember seeing this behavior a while back when using msp-gcc directly on Linux. I'll try the same board/sketch on OS X next. Maybe I'm missing some basic here. Any additional help appreciated.
  • Create New...