Hello all: I have never posted on Stackoverflow, but I have always come here for help for years.
I have a question and problem regarding debugging in eclipse using an STLINK STM32 Discovery board. I have looked online for the answer and have followed many tutorials, but I still cannot seem to get it to work correctly. I will try my luck at asking here.
I have set up the eclipse environment correctly with my compiler and gdb server (to my knowledge). First I make sure the server is started before I press debug in eclipse. I am using Atollic STLINK gdb server. I have tried many arm-none-eabi-gdb type exe's while debugging, but they all seem the same. My debug configuration is setup to use arm-none-eabi-gdb on port 61234 (Attolic). When I press debug, the program launches correctly and goes into the debug view in eclipse. The program downloads correctly to my discovery board. I know this because I have gotten debugging to work partially and have stepped through the code without crashing on 'some' occasions depending on the compiled code and debug configuration startup options. The code is a simple LED turn on on the board. If I unplug the usb cable and plug it back in, my code runs fine, because the LEDs light up, so we know the environment is probably set up correctly, because the code downloads to flash via eclipse commands.
The problem is with actual debug steps. 99% of the time the arm-none-eabi-gdb.exe program crashes when in the debug view after I do a few "step into's" with the debugger commands at the top of eclipse. After the first line of my main function is reached, I will try to step into the first line and I get a windows crash of the arm-eabi.exe program. The debug console in eclipse reads a gdb error: .......dwarf2: C10xx Internal Error - unknown CFA rule. Now... depending on how I set the options in the debug configuration with regards to the startup tab, different options produce different results and the following options have been toggled: Halt, resume, break point at : main, etc.. This crash also seems to be dependent on the code being compiled in the main function.
Now, does this have any dependency on which compiler is used with the gdb server and arm-none-eabi-gdb.exe programs? For instance, if I compiled the code with Atollic versus Keil versus code sourcery versus IAR, would the Attollic gdb service + arm-none-eabi-gdb programs be able to work with any compiled code? Are there some missing symbols somewhere not being generated? For reference, I am using an EVAL version of the IAR compiler tool set. If I make a project with the same code in embedded workbench using the STLINK, the code compiles and debugs fine.
What is a CFA rule? Call frame address? Am I not setting up the stack pointer or something in my program? I thought the IAR compiler took care of all that junk in the cstartup.
Any help is appreciated.
Thanks,
LostTime77
Related
I am currently using mac OS to set up a debugger to debug Mbed OS application , I followed the instruction from https://os.mbed.com/docs/mbed-os/v5.12/tutorials/eclipse.html .
I successfully set up the local debug toolchain and I am stuck at this error for quite awhile already. I install "make" as written in the documentary using homebrew and also set the path as suggested but still getting this error
00:13:27 **** Incremental Build of configuration Default for project mbed-os-example-blinky ****
make all
Cannot run program “make”: Unknown reason
Error: Program “make” not found in PATH
PATH=[/Users/roseyv/Developer/gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-g++]
00:13:27 Build Failed. 1 errors, 0 warnings. (took 4ms)
Any idea how to resolve this issue? or if there is any other better way we can set up debugger to debug MBED os application
Your help will be greatly appreciated, Thank you in advance!
In the mean time Mbed has updated their website. The link you posted is no longer valid. My suggestion now would be to use Mbed Studio.
Unfortunately Mbed is moving away from supporting Eclipse and only supports IDE's for which you have to be logged in with your account, Mbed Studio or the online compiler.
You could build from the command line option. Next use something like a Segger j-link and Segger Ozone to debug. I found Ozone easier to setup with random code compared to embedded debugging on Eclipse. This is what you pay for.
So I have anaconda installed and make a separate environment for all my projects. Normally I just use PYDEV to create a new interpreter pointing to the anaconda enviornment and load the project in eclipse and all is good. After doing the last one though 95% of the time I go to debug I keep getting the error
An internal error occurred during: "Debug Source Lookup".
java.lang.IllegalArgumentException
The other 5% it kind of works as I can follow one script or a function before it starts breaking.
I've tried reloading the project, interpreter and conda enviornment to no luck. All my past projects which use to work are also now giving the same error.
The funny thing is when I'm in the debug perspective though it does seem to be working (I can see the Variables and use the interactive console to test stuff), but anytime I try to step into, over ect I get the error (even though it does seem to be working). So for the image above I can go through the code fine until it tries to jump to the other file which throws the error, but if I step into it I can manually open that file and walk through the function (just each step throws the error) and still interact with the code which is in the position through the console.
Any ideas how to fix?
Well, it may be something specific to this use-case (for instance, if the code for some object is evaluated and the source code is not really available for the debugger this is actually expected).
Can you provide the full stacktrace from the error log? (see: http://www.pydev.org/faq.html#HowdoIReportaBUG for details on how to get it)
I've been developing a project (in C) for an STM32F105, using the Eclipse IDE with CDT plugins. I'm using the gcc-arm toolchain, OpenOCD (gdb) for debugging, and an ST-Link/V2 JTAG device.
I've been debugging on my target board, no problems.
Now, I finally want the code to run by itself, and I don't know how to do it in Eclipse! I'm sure it's simple, but I can't find it.
How do I build the code and program my target so that it runs "normally"?
Configure OpenOCD as external tool and use arguments more or less like these:
-f interface/... -f target/... -c "init; reset init; flash write_image erase <your_hex_file.hex>; reset run; shutdown;"
You should of course adapt this command to your project: enter proper interface and target configs and set right name of hex file (you can also use .bin or .elf, but .hex is usually the most convenient).
In the "Working Directory" textbox enter your project directory - use "Browse Workspace" to do that, you should have sth like this there: ${workspace_loc:/<name_of_your_project>}
One of my projects worked by simply disconnecting the debugger and resetting the target, as suggested by #ChrisStratton. The other didn't, whether I used the IDE or the ST-LINK tools. It worked fine when the debugger was attached.
It turns out that the non-working program was using semi-hosting. When I disabled semi-hosting by removing the following compiler symbols, the project started running just fine on its own.
I'm currently working on a project on STM32F4 and I'm using Eclipse. I've got some problems with the program - it seems to have a random behavior - sometimes it works fine, other times it has some errors. Sometimes when I try do debug with breakpoints I get the beautiful HardFault Handler and it really messes with my brains.
Sorry for the little off-topic paragraph, just wanted to let you know why I decided to use printing to a log file at some key moments in the program so I can see in which states and in which functions does the problem occur. I'm debugging through a JTAG interface with Eclipse (gdb) and I need to know if there is an easy method integrated in Eclipse that may help me use fprintf-like functions inside my program to write to a file on the disk.
If no, any other solutions?
Thanks
I do not like to connect the debug output log to the Jtag communication port because the log will not be available after development.
I usually build an SystemLog library that can send the log messages through any medium that is available (UART, USB, Ethernet or SDCARD). That's what I'd recommend you to do. It will help you through the development, and the support team on the event of any failure on field.
If stdlib is available in your project you should use the snprintf family functions to build your SystemLog.
Also, you can integrate the log output to the eclipse console by calling a serial console communicator (if you use UART) on you makefile, in this case, your makefile will have to flash the target as well.
I presume that the debugger is configured correctly (but what else can it be)?
If I look at Tools/Options/C/C++ it is set up nicely for Cygwin_4.x and the toolset programs all exist (especially C:\cygwin\bin\gdb.exe) Since I can build and link ok, and this all gets setup by NetBeans discovery of the toolset, I would expect to be able to debug.
The only minor detail is that C:\users\mawg.gdbinit does not exist. I supplied an empty file to no avail. IIRC from form running GDB by hand 20 years ago it isn't necessary.
If I Ctrl+F5 (debug main project (I have only one)) or Alt+F6 (run all test files) the application runs and produces output ... I can also "step into" and proceed with F7 & F8 ...
... but it won't stop on breakpoints.
I guess that I am missing something very simple. Who can point it out to me, please? Thanks
OK, I could just delete this question, but I will post the "answer" just so others might have one more thing to check if they have the same problem.
Not being able to debug with Netbans, I tried MS visual studio and it reported that I had an opening
#ifdef __cplusplus
extern "C" {
#endif
without the corresponding close.
This is not a NetBeans problem; it is a GCC compiler problem, from GCC of Cygwin, I will report this to GNU/GCC.
Moral: migh be worth checking; but it is always worth running problematic code through a few different compilers and linters.