-run-exec in Eclipse --> CodeSourcery/arm-none-eabi-gdb --> gdb --> Atollic/gdbserver ? [message #793050] |
Tue, 07 February 2012 18:05 |
Mark Becker Messages: 5 Registered: February 2012 |
Junior Member |
|
|
Hello -
Cross-development effort. Host is a Windows XP SP3 system loaded with the Atollic Lite package for ARM and the CodeSourcery Lite package for compile/link/etc.
I've been trying to get an LED blinker running in an STM32F4_Discovery board.
The board is connected to the computer with two USB cables; one on the debug port, the other to the data end.
Here's one site with instructions and a note that Indigo was good:
shareee_dot_netne_dot_net/wordpress/?p=5
Compiling the sample code (LED_Blink) goes smoothly. Both hex and binary files are built. But trying to run or debug the code in the target produces an error:
+==============================================
| Error in final launch sequence
| Failed to execute MI command:
| -exec-run
| Error message from debugger back end:
| Don't know how to run. Try "help target".
| Don't know how to run. Try "help target".
+==============================================
gdbserver did start. When it does, the Discovery board LED's stop flashing.
I can manually run gdb from the command line and load binaries into the target. That part works. It's awkward to use... but it does work. However, the Eclipse debugging end of things ... won't run due to the problem above.
A cut/paste from a log file is attached below.
A .gdbinit file is called out in the debugger setup pane... but I haven't been able to find it in either the Workspace or Eclipse trees.
Is there a way to suppress the "-run-exec" that's bothering gdb ? Or have I loaded the wrong CDT package?
Thanks.
eclipse.buildId=M20110909-1335
java.version=1.6.0_30
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.cpp.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.cpp.product
!ENTRY org.eclipse.cdt.core 1 0 2012-02-07 11:56:21.937
!MESSAGE Indexed 'LED_Blink' (34 sources, 60 headers) in 5.59 sec: 6,211 declarations; 24,067 references; 3 unresolved inclusions; 0 syntax errors; 1 unresolved names (0.00%)
!ENTRY org.eclipse.cdt.dsf.gdb 4 5012 2012-02-07 12:08:50.312
!MESSAGE Error in final launch sequence
!STACK 1
org.eclipse.core.runtime.CoreException: Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don't know how to run. Try "help target".
at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:114)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:211)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:98)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:87)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:854)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:928)
at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1132)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.Exception: Don't know how to run. Try "help target".
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:889)
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:720)
!SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2012-02-07 12:08:50.312
!MESSAGE Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don't know how to run. Try "help target".
!STACK 0
java.lang.Exception: Don't know how to run. Try "help target".
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:889)
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:720)
|
|
|
|
|
|
|
|
Re: -run-exec in Eclipse --> CodeSourcery/arm-none-eabi-gdb --> gdb --> Atollic/gdbserver ? [message #793155 is a reply to message #793093] |
Tue, 07 February 2012 20:46 |
Mark Becker Messages: 5 Registered: February 2012 |
Junior Member |
|
|
I looked:
F:\Program Files\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin\arm-none-eabi-gdb.exe
That's the right place.
And here's the server in External Tools Configurations:
F:\Program Files\TrueSTUDIO for STMicroelectronics STM32 Lite 2.3.0\Servers\ST-LINK_gdbserver\ST-LINK_gdbserver.exe
The config file for ST-LINK_gdbserver.exe specifies port 61234 .. and so does the entry in Eclipse for launching the debugger.
There's a C/C++ Remote Application entry in the Debug Configurations pane but I cannot specify it to do anything. Eclipse keeps renaming the any entry to something else... and then more error messages pop up.
Just loaded RSE .. and it's not in the Debug Configurations pane.
Back to reading web pages...
Mark
[Updated on: Tue, 07 February 2012 20:48] Report message to a moderator
|
|
|
Re: -run-exec in Eclipse --> CodeSourcery/arm-none-eabi-gdb --> gdb --> Atollic/gdbserver ? [message #794059 is a reply to message #793155] |
Wed, 08 February 2012 22:03 |
Mark Becker Messages: 5 Registered: February 2012 |
Junior Member |
|
|
Hello Marc -
Tuesday evening I *finally* got things to the point where the project could be compiled, linked, *and* got the debugger running. And I did it three more times, from Ground Zero, just to make sure getting the configuration right wasn't a fluke. Went home.
Return Wednesday... and nothing worked properly. Spent most of Wednesday re-jumping through hoops to get it running again. This time I took notes.
Here's what I did for creating a new debug configuration.
Run --> Debug Configurations brings up a large pane titled "Debug Configurations".
Right-click under GDB Hardware Debugging and create a new configuration. When I did this with the project set to "LED_Blink", the name of the generated configuration was set to "LED_Blink Debug".
In the Main tab, The C/C++ Application is set to Debug\LED_Blink.elf .
Project was set to LED_Blink.
Just below that there is the boxed area labeled "Build (if required) before launching".
Build configuration --> Use Active .
The radio button for "Use workspace settings" is on.
At the bottom of that pane, it has "Using GDB (DSF) Hardware Debugging Launcher". Left-clicking on "Select other" brings up a "Select Preferred Launcher" pane. At the bottom of that, under "Description" it has, "Jtag hardware debugging u sing the Debugger Services Framework (DSF)". I didn't change that.
Back in the Debug Configurations pane, there is the Debugger tab. I have the GDB command set to CodeSourcery's arm-none-eabi-gdb.exe . The boxed area labeled "Remote Target" has the "Use remote target" checkboxed checked. JTAG Device is "Generic TCP/IP", host name is localhost, and the port number is 61234.
-----
Now.. I select the C++ perspective, select Console, and start gdbserver (per directions in the sharee site). It's pretty obvious when the server successfully starts. That.. and the STM32F407 board stops flashing those four LED's and LD1 flashes red and green.
Whapping F11 (Debug) brings up the Debug perspective... and one long moment later up pops all the pretty debugging windows. It comes up in startup_stm32f4xx.S.
After all that... now I think I can start writing code.
======
Remaining problems:
1. In the Problems tab, there are eight errors of symbols that could not be resolved. One header file had not been #include'd so that was fixed. The source code now compiles... but Eclipse seems unable to resolve those eight symbols.
(It calls this a "Semantic Error". But the compiler compiles it anyway.)
2. According to the user manual for the Discovery board, jumpers can be changed to put RAM at address 0x0 which might be a good idea while debugging. I'm a little unsure as to what to change in the .ld file to get all the modules in the right places to make that happen properly.
Cheers.
Mark
|
|
|
|
Powered by
FUDForum. Page generated in 0.04435 seconds