Sysprogs forums › Forums › VisualGDB › Poor performance with MSP430F5529 launch pad
Tagged: MSP430 msp430-gdbproxy++
- This topic has 4 replies, 2 voices, and was last updated 7 years, 2 months ago by support.
-
AuthorPosts
-
September 26, 2017 at 12:22 #12515wtywtykkParticipant
Hello,
I’m using gdbproxy++ v1.8 and toolchain 4.6.3/7.4/r7 . The program is small,but it takes more than one minute to load the program. I tried to use gedproxy++ and gdb instead of debugging it in Visual Studio. The load command only takes a few seconds. I’m quite sure something in VisualGDB slows down the command. Could you figure out what’s wrong and fix it?
September 26, 2017 at 12:30 #12516wtywtykkParticipantThe debugger on the launchpad is eZ-FET lite. I’m not sure whether it’s related.
September 26, 2017 at 21:31 #12517supportKeymasterHi,
No problem, we can walk you through pinpointing and resolving this. First of all, please ensure that you are using exactly the same version of msp430.dll and msp430-gdbproxy both in command-line mode and from VisualGDB.
If both versions are the same, most likely the slow behavior is caused by some command-line argument or gdb command. Please try enabling advanced gdb logging via VisualGDB Project Properties -> Advanced GDB Settings. This will create a .log file with all gdb commands issued by VisualGDB as a part of your debug session. Then please try running gdb/gdbproxy manually with the commands shown by VisualGDB and run the same commands (you can skip commands for evaluating sizeof(void *) and other built-in types).
Can you reproduce the slow behavior by running the commands manually? If yes, please try removing some of them to see which of them causes the slowness. If no, what happens if you launch gdbproxy manually and change GDB settings on the Debug Settings page of VisualGDB Project Properties to “manual mode” and explicitly specify the “target remote :<port>” command? If this works faster, some environment variable that is only present when launching from VS might be affecting the msp430.dll behavior.
September 27, 2017 at 06:01 #12522wtywtykkParticipantHi,
I’m quite surprised. The “-break-insert -f main” command causes the problem. If I run it before “load”, gdb will break the program into really small pieces and then download them one by one. And if I run “load” before “-break-insert -f main”, there’s no problem.
So I tried to add “-break-delete 1” in the “Additional GDB Commands” tab to remove this break point before download. It works,but is there any side effect?
September 27, 2017 at 20:13 #12526supportKeymasterHi,
Thanks for checking this. We were not aware of it and it looks like something specific to the msp430 gdb and the device you are using. The only side effect of this would be that the ‘step into new instance’ command (or pressing F10 instead of F5) will not work. Other features should not be affected by this.
P.S. You can also disable the breakpoint in ‘main’ by unchecking the checkbox shown below on the Advanced GDB Settings page of VisualGDB Project Properties:
Attachments:
You must be logged in to view attached files. -
AuthorPosts
- You must be logged in to reply to this topic.