Author Topic: MSP430 linux toolchain with C::B (Read 35535 times)

ywi · « **on:** May 11, 2012, 11:53:50 am »

Hello Developers,

First, thank you for supporting this project. I've been using C::B over the last few years on both Linux and Windows and I find it light and friendly.
I am currently using C::B as IDE for developing and debugging code on an MSP430-based embedded target. I would like to address here some issues and several amelioration that would help a better integration of the mspgcc toolchain in C::B (mspgcc + mspdebug). Of course I would be ready to contribute as far as I can.

Thank you in advance for your support,
Yordan

Here a list of issues/ameliorations:

1) CPU register is empty. How to setup correctly this window for mspgcc?
2) Impossible to select another debugger executable than GDB with the latest nightly build (would need to be msp430-gdb)
3) Need to send some default commands to mspdebug when msp430-gdb connects to it ("target remote :2000", "erase", "load"...). Would ideally like to write a new plugin for mspgdb with an extra button to load code to the remote, based on the debugger plugin. Would appreciate to get some support on this.

oBFusCATed · « **Reply #1 on:** May 11, 2012, 12:32:11 pm »

1) What is the output of the cpu registers gdb command? Does it look like the one for x86?
2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?
3) Have you tried the settings in Project -> Properties -> Debugger?

ywi · « **Reply #2 on:** May 11, 2012, 03:28:42 pm »

1) What is the output of the cpu registers gdb command? Does it look like the one for x86?

-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window

2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?

-> Thx, I did not catch that upda

3) Have you tried the settings in Project -> Properties -> Debugger?

oBFusCATed · « **Reply #3 on:** May 11, 2012, 03:35:21 pm »

Quote from: ywi on May 11, 2012, 03:28:42 pm

-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window

I said output, not the command. Paste it please.

ywi · « **Reply #4 on:** May 11, 2012, 04:08:20 pm »

1) What is the output of the cpu registers gdb command? Does it look like the one for x86?

-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window

2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?

-> Thx, I did not catch that update. I can now configure my own debugger, but I get the following error message when I run it: "Starting the debuggee failed: Don't know how to run." I do not have this message with 10.05 ("do *not* run the debugee" option is disabled in both cases). When I use a custom command file (-x option) I don't get the previous error, I can talk to the proxy, erase and load the flash, but gdb does not seem to release the target from reset, so I cannot debug.

3) Have you tried the settings in Project -> Properties -> Debugger?

Yes, I call the proxy as an additional shell command, but it does not seem to work. But I still need a separate button to load the flash.

ywi · « **Reply #5 on:** May 11, 2012, 04:18:09 pm »

> regs
Use 'info registers'.
pc/r0: 9800 sp/r1: 1cfa sr/r2: 0000 r3: 0000
fp/r4: 0000 r5: 5a8c r6: 0000 r7: 0000
r8: 0000 r9: 0000 r10: 0000 r11: 0000
r12: 0000 r13: 0022 r14: 0182 r15: 0519

oBFusCATed · « **Reply #6 on:** May 11, 2012, 04:27:44 pm »

Quote from: ywi on May 11, 2012, 04:08:20 pm

-> Thx, I did not catch that update. I can now configure my own debugger, but I get the following error message when I run it: "Starting the debuggee failed: Don't know how to run." I do not have this message with 10.05 ("do *not* run the debugee" option is disabled in both cases). When I use a custom command file (-x option) I don't get the previous error, I can talk to the proxy, erase and load the flash, but gdb does not seem to release the target from reset, so I cannot debug.

Steps to reproduce please, because I don't understand much of what you've written.
Keep in mind that I'm not embedded developer and proxy/reset/erase-load doesn't mean much to me.

ywi · « **Reply #7 on:** May 11, 2012, 05:09:26 pm »

Case 1 :
=====

I configure the following :
Settings -> Debugger -> GDB Debugger -> MSPGDB -> execute path : /usr/local/bin/msp430-gdb
Settings -> Debugger -> GDB Debugger -> MSPGDB -> arguments :

I run the debugger :

...
Starting debugger: /usr/local/bin/msp430-gdb -nx -fullname -quiet -args /projects/cb/test/bin/Debug/test
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2
Starting the debuggee failed: Don't know how to run. Try "help target".
Debugger finished with status 0

Case 2
=====

a) I configure the following :
Settings -> Debugger -> GDB Debugger -> MSPGDB -> execute path : /usr/local/bin/msp430-gdb
Settings -> Debugger -> GDB Debugger -> MSPGDB -> arguments : -x /usr/local/msp430/gdb.ini

b) gdb.ini contains commands for the mspdebug proxy :

target remote :2000 // connect to the proxy
erase // erase flash
load // load executable to flash
continue // release CPU from reset

c) I run the proxy, then I run the debugger:

The debugger connects successfully to the proxy, the commands are passed to the proxy and executed successfully. But then I lose control on gdb (I can push the buttons, write commands in the command line, but they are not taken into account).

"do *not* run the debugee". It is disabled in both cases.

oBFusCATed · « **Reply #8 on:** May 11, 2012, 05:46:26 pm »

Have you tried to setup the remote debugging options for your project in Project -> Properties -> Debugger-> Remote connection?

p.s. All please enable the full log in the Settings->Debugger, before posting more logs from the debugger...

ywi · « **Reply #9 on:** May 11, 2012, 07:31:32 pm »

I set the remote connection in Project -> Properties -> Debugger-> Remote connection. It works. I not have the "Don't know how to run" error anymore (Case 1, default setting and not using a command file). I can see the gdb connect to the proxy and send the "continue" command. I then lose control over the command line and the buttons. I can stop gdb only by killing the proxy.

Here is the full log :

Code

Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: /projects/cb/test/
Adding source dir: /
Adding file: /projects/cb/test/bin/Debug/test
Changing directory to: /projects/cb/test/.

[debug]LD_LIBRARY_PATH=.:/projects/cb/test:/usr/local/lib:
[debug]Command-line: /usr/local/bin/msp430-gdb -nx -fullname  -quiet  -args /projects/cb/test/bin/Debug/test
[debug]Working dir : /projects/cb/test

Starting debugger: /usr/local/bin/msp430-gdb -nx -fullname  -quiet  -args /projects/cb/test/bin/Debug/test
done

[debug]Reading symbols from /projects/cb/test/bin/Debug/test...done.
[debug](gdb) 
[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints

[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.2
[debug]Copyright (C) 2010 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=msp430".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.2

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/cb/test/
[debug]>>>>>>cb_gdb:
[debug]> directory /
[debug]>>>>>>cb_gdb:
[debug]> target remote tcp:127.0.0.1:2000
[debug]Queued:[tty /dev/pts/3]
[debug]_reset_vector__ () at ../../../gcc-4.5.3/gcc/config/msp430/crt0.S:118
[debug]/home/toto/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118:3824:beg:0x9800
[debug]>>>>>>cb_gdb:

Connected

[debug]> tty /dev/pts/3

At /home/toto/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118

[debug]> tty /dev/pts/3
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> continue

EDIT:
Please use code-tags if you post such an amount of log entries or source-code the next time, because it's much more readable.
I changed your post.

Jens

oBFusCATed · « **Reply #10 on:** May 11, 2012, 08:32:26 pm »

Does it work if you execute the same commands in a command line gdb?

Also what happens if you put a breakpoint before you start the debugger?

ywi · « **Reply #11 on:** May 12, 2012, 02:07:10 am »

It works OK as command line and with 10.05. I will be able to answer the second question on Monday. Thx.

oBFusCATed · « **Reply #12 on:** May 12, 2012, 09:58:29 am »

Can you post the log from command line debugger?
But make sure to execute all gdb commands C::B is executing...

ywi · « **Reply #13 on:** May 14, 2012, 06:56:11 pm »

This is the minimal commands executed on msp430-gdb

Code

Reading symbols from /projects/cb/test/bin/Debug/test...done.
(gdb) target remote :2000
Remote debugging using :2000
_reset_vector__ () at ../../../gcc-4.5.3/gcc/config/msp430/crt0.S:118
~/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118:3824:beg:0x9800
(gdb) break *0xdcd0
Breakpoint 1 at 0xdcd0: file /projects/cb/test/test, line 79.
(gdb) continue
Continuing.

Breakpoint 1, plat_mpipe_rx_isr (id=2) at /projects/cb/test/test.c:79
/projects/cb/test/test.c:79:2857:beg:0xdcd0
(gdb)

I found that the difference with the nightly is that it sends the command "run" rather than "continue" to continue after a break. msp430-gdb does not support (for some reason) the command "run". I think we can consider this is more a problem with msp430-gdb than the nightly, unless there some other reason to differentiate both.

Maybe at this point you can explain to me the usage of the config "do *not* run the debuggee".

Also, for remote target debugging it is mandatory to have two separate buttons in the debugger toolbar, one to burn the code on the remote's flash, the other to start/continue. Burning takes some time and you do not want to burn every time you start a debugging session.

I would appreciate your suggestions on how to display the regs information in the appropriate debug window.

Than you.

oBFusCATed · « **Reply #14 on:** May 14, 2012, 07:01:38 pm »

Hm, as far as I can see in your previous logs continue is used, as it should.
There is no run in the log.

"do *not* run the debuggee" - does not run the debuggee, just starts the debugger, sets the breakpoints and probably connects to the target, then the user has to press the continue button in order to start debugging.

How do you burn something to a flash? I don't think C::B knows how to do it.

ywi · « **Reply #15 on:** May 14, 2012, 08:21:44 pm »

The latest nightly debugger plugin passes command "run" instead of "continue" when the run/continue button is pressed:

Code

Debugger name and version: GNU gdb (GDB) 7.2

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/test/
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/
[debug]>>>>>>cb_gdb:
[debug]> tty /dev/pts/3
[debug]Queued:[tty /dev/pts/3]
[debug]>>>>>>cb_gdb:

Continuing...

[debug]> run
[debug]Don't know how to run.  Try "help target".
[debug]>>>>>>cb_gdb:

Starting the debuggee failed: Don't know how to run.  Try "help target".

[debug]> quit

Debugger finished with status 0

For burning the flash, gdb send specific commands (erase, load, ...) to the debugger proxy, which is himself connected to a programmer.

oBFusCATed · « **Reply #16 on:** May 14, 2012, 11:08:11 pm »

For the burning: Then you need to put the commands in a file and then use the source command in combination with the 'do not run mode'.

For the run command: I see no remote debugging commands, so I guess you've not set them and you're in native/local debugging mode, thus run is the normal command to use.

ywi · « **Reply #17 on:** May 14, 2012, 11:23:21 pm »

Yes, I already used successfully a file at gdb start to run particular commands. But still sometimes gdb is launched and reprogramming the flash is not necessary. How to distinguish between both? Usually tools working on remote targets have separate buttons for connect to target and burn.

For your second comment, could you give me some details on where to set "native" and "remote" specific mode parameters?

Thx.

oBFusCATed · « **Reply #18 on:** May 15, 2012, 10:09:14 am »

Quote from: ywi on May 14, 2012, 11:23:21 pm

Yes, I already used successfully a file at gdb start to run particular commands. But still sometimes gdb is launched and reprogramming the flash is not necessary. How to distinguish between both? Usually tools working on remote targets have separate buttons for connect to target and burn.

Do you see the edit box at the bottom of the debugger's log?
There you can enter commands, so if you're in do-not-run mode you can start gdb then if necessary you can execute the source command manually and then you can start debugging.
Isn't this what you want?

Quote from: ywi on May 14, 2012, 11:23:21 pm

For your second comment, could you give me some details on where to set "native" and "remote" specific mode parameters?

I already have shown you - in the project -> properties -> debugger -> remote...

ywi · « **Reply #19 on:** May 15, 2012, 12:15:50 pm »

OK, I have all information on the configuration possibilities of the debugger. It can partially cover remote debugging needs. As I mentioned, sometimes gdb is launched and reprogramming the flash is not necessary, so a separate toolbar button to burn the flash would be a plus.

Could you help me on the registry window problem? Here is the information printed with command "info registers":

Code

pc/r0: a702  sp/r1: 2bb0  sr/r2: 001b     r3: 0000  
fp/r4: ffff     r5: 5a0c     r6: ffb4     r7: ffff  
   r8: ffff     r9: ffff    r10: ffb4    r11: ffff  
  r12: 0001    r13: 0000    r14: 0340    r15: 0000

Thanks.

oBFusCATed · « **Reply #20 on:** May 15, 2012, 12:36:23 pm »

I guess you have to set the proper disassembly flavor.
See here: http://forums.codeblocks.org/index.php/topic,16336.msg110619.html#msg110619
I don't know what is the correct/proper disassembly flavor, read the manual of you gdb about it.

If not you'll have to modify the cpu registers parser and provide a patch.

ywi · « **Reply #21 on:** May 16, 2012, 01:24:10 pm »

OK. Thx for this overview of the debugger configuration possibilities.

ywi · « **Reply #22 on:** May 18, 2012, 05:43:59 pm »

Is there any simple codeblocks plugin example (ideally a toolbar with just one button that when pushed calls a shell command) ? It will be quite easy to build a remote connect and flash burn contrib plugin out of it.

Thanks.

MortenMacFly · « **Reply #23 on:** May 18, 2012, 06:38:09 pm »

Quote from: ywi on May 18, 2012, 05:43:59 pm

(ideally a toolbar with just one button that when pushed calls a shell command) ? It will be quite easy to build a remote connect and flash burn contrib plugin out of it.

For such purposes, there is the Tools / Tools+ plugin that can do such quite handy. No need for another plugin.

ywi · « **Reply #24 on:** May 18, 2012, 07:42:30 pm »

Well, that's great, thanks. Would be nice this menu to create its own toolbar.

ywi · « **Reply #25 on:** May 18, 2012, 08:50:05 pm »

I come back to a request for monitoring specific remote registers (not only the remote CPU registers). What I basically need is to be able to load at C::B start a memory map description file of volatile variables that gdb will have to update at each step/bkp. Any suggestions?

MortenMacFly · « **Reply #26 on:** May 18, 2012, 11:01:01 pm »

Quote from: ywi on May 18, 2012, 08:50:05 pm

I come back to a request for monitoring specific remote registers (not only the remote CPU registers). What I basically need is to be able to load at C::B start a memory map description file of volatile variables that gdb will have to update at each step/bkp. Any suggestions?

Use the debugger initialisation commands and (if needed) the debugger console for that purpose.

ywi · « **Reply #27 on:** May 19, 2012, 07:23:20 pm »

This is not quite convenient. It should behave like a watch, i.e read and display automatically the list of remote registers (addresses). GDB should execute command "x/b <addr>" for every address of the registers address list when a bkp/step is reached.

oBFusCATed · « **Reply #28 on:** May 19, 2012, 07:34:09 pm »

I guess you can use python enabled gdb and use some fancy python scripts...

ywi · « **Reply #29 on:** May 19, 2012, 08:14:29 pm »

That is an interesting option indeed, but maybe too fancy for me for the moment. Is there any possibility to pass commands to the GDB launched by C::B by an external shell command?

oBFusCATed · « **Reply #30 on:** May 19, 2012, 10:43:57 pm »

No, but you can load a file.

ywi · « **Reply #31 on:** May 21, 2012, 05:06:47 pm »

I found a solution using just the watch mechanism of C::B. Actually gdb will execute

Code

output ...

where "..." is the content of a line of the watch file. For example when variables toto, blabla, ole are watched, the content of the watch file is

Code

toto
blabla
ole

Now, it is possible to add more arguments in the watch file, or read absolute addresses instead of symbols. For example output /x (my_type)*0x1234 will read at address 0x1234 and interpret it as a variable of type my_type in hexadecimal. Subsequently it is possible to read remote content by 1) defining a structure containing the remote registry (let say msp430_regs_t in my case) 2) adding in a default watch file

Code

 /x  (msp430_regs_t)*0xXXXX

where 0xXXXX is the registry base. I checked that this is correctly interpreted by C::B.

Regards, Yordan

ywi · « **Reply #32 on:** May 21, 2012, 08:15:01 pm »

One (probably) last question : is it possible to automatically load a watch file at the beginning of a debug session (or project open) ?

tux-tor · « **Reply #33 on:** July 08, 2012, 12:33:18 pm »

Are you aware of the .gdbinit and .mspdebug files where some presets can be made? regards, Kees

News:

Author Topic: MSP430 linux toolchain with C::B (Read 35535 times)

tux-tor