Jump to content
43oh

Programming Hangs on Linux


Recommended Posts

Finally got compilation working on Linux (Ubuntu 11.10, kernel 3.0.0-17) at least for the Blink sketch. But when I try to program the board/chip It hangs forever like this:

 

Experimental: JNI_onload called.

Stable Library

=========================================

Native lib Version = RXTX-2.1-7

Java lib Version = RXTX-2.1-7

 

Binary sketch size: 469 bytes (of a 8,192 byte maximum)

Binary sketch size: 469 bytes (of a 8,192 byte maximum)

rf2500: warning: can't detach kernel driver: No data available

Trying to open interface 1 on 004

Device: MSP430G2452

Erasing...

Programming...

 

I can see /dev/ttyACM0 in /dev and I am running Energia as root in an attempt temporarily to avoid various permission problems.

 

Any idea what I am doing wrong here?

Link to post
Share on other sites

Energia expects to find the mspdebug in your path. It seems like that is working because you are seeing some output. Shutdown Energia and try using mspdebug from the command line and see if you can interact with your launchpad.

 

# mspdebug rf2500

 

You should be able to connect to the device, it should tell you what chip is in the socket. You should be able to type help and see if you can do various commands. If you can interact with it, find the /tmp/build*/ directory where your program/sketch got compiled and see if you can load it outside of Energia. The file you want to load will be the name of your program with .elf on the end. You can download it to your chip using:

 

# mspdebug rf2500 "prog something...elf"

 

If that doesn't work then take a look at the output of 'dmesg' see if there is anything strange. Stop Energia, unplug your launchpad and then do a tail -f /var/syslog. Plug in your launchpad and see if anything indicates some problem.

 

Try compiling mspdebug from source. It is a program that is being constantly improved. I found a bug a couple of weeks ago that was fixed a couple of hours later. You want the latest version.

 

Did you have the right chip selected? If not it will just fail because the code you compiled won't match the one in the launchpad. Depending on the chip it may work, or may just act completely wonky. Turn on verbose output in preferences and see if it indicates anything.

 

Things to remember about a launchpad:

 

1.) It isn't an Arduino. It doesn't need a boot loader. There is nothing sent down the serial line to program the chip. The only two pins that matter when downloading software to it are the TEST and RST pins and of course VCC and GND. The launchpad talks a 2 wire JTAG protocol called SpyBiWire (SBW) with mspdebug.

2.) The serial port doesn't matter. Unless you are trying to use it of course.

3.) The serial port driver for linux sucks. (the cdc_acm driver). Find the replacement driver and get it to work on your machine.

4.) When the serial port driver hangs, It hangs Energia, it hangs your whole system, everything.

5.) When you find and install the replacement cdcacm life is good and your system doesn't hang and Energia works nicely.

 

You should install the udev entry so you don't have to run as root. Running as root leaves you open to breaking things by accident.

 

Good luck and let us know if you make any progress.

-rick

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 3 weeks later...

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.

Link to post
Share on other sites

instead of using erase and load, use "prog yourfile.elf " it will load debugging symbols as well as erase and write to flash , so you have a better idea what it is doing when trying to debug.

 

also try using the reset command before runing, using step is a good way to see what is run step by step.

 

one last thing, could you upload your elf files that are giving you issues? Some of us might be able to dig into them to see whats going on.

Link to post
Share on other sites

I cloned the latest mspdebug using git:

 

git clone git://mspdebug.git.sourceforge.net/gitroot/mspdebug/mspdebug

 

Then I rolled back to this version using:

 

git checkout e02567a7123817660db15649a76d64aa3314a257

 

If I use the latest version, the reset button on the launchpad no longer works. Using an older version of mspdebug to upload the same elf file works fine. There is a recent checkin that looks suspect to me, so I went to the check-in just before that one. That is the e02567a7123817660db15649a76d64aa3314a257 in checkout line above.

 

I uploaded linux binaries to the Energia github for the msp430-gcc and mspdebug that seems to work for me. You might want to try them or wait a bit and there will be a new binary distribution of Energia.

Link to post
Share on other sites

(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

Something is fishy here. Those sections .rodata.* .. those look like they are getting loaded into ram instead of flash. 0x200 is the start or ram. The .rodata sections should be going into flash some where around 0xc100 after the .text section. "rodata" is the read only data that is copied to ram at startup. Something strange going on there...

 

This is what my mspdebug output looks like when loading the Blink program:

Device: MSP430G2553
Code memory starts at 0xc000
Number of breakpoints: 2
Erasing...
Programming...
Writing  520 bytes to c000...
Writing   32 bytes to ffe0...
Done, 552 bytes written

 

-rick

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...