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.
Related
I am attempting to upload my written program for the STM32F411RE from my TrueStudio for STM32 IDE to the board itself. The board is connected via the mini USB b cable and the intent is to program it via SWD.
Setup
Atollic provides a nice tutorial on how to perform this programming via it's TrueStudio IDE and the ST-Link_CLI (Command Line Interface), as described in the document at this link. This requires the following steps, which I have followed and checked multiple times:
First and foremost the output (binary) file needs to be an intel .HEX and
not the TrueStudio .elf default. To change this go to Project properties -> c/c++ build -> settings -> tool settings tab -> other -> Output format
and tick the option 'Convert build output', ensure that the Intel Hex
option is selected in the dropdown.
To call the ST-Link_CLI from inside the IDE requires making an external
tools configuration. To make this config I go to Run -> External Tools ->
External Tools Configurations .... and create a new configuration, lets
call it ST-Link_CLI. For the Working Directory I specify the directory of my ST-LINK_CLI
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility)
whilst for the Location I specify this directory and the file name
(C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK
Utility\ST-LINK_CLI.exe).
Lastly, I add the following parameters to
identify the STM32 board, have it connect via SWD and under reset, whilst
telling it to upload the .HEX file built by TrueStudio
(-c ID=0 SWD UR LPM -P ${project_loc}\Debug\${project_name}.hex -v).
Output
When I then call this external tool configuration via the Run -> External Tools -> ST-Link_CLI link just created I get the output listed below:
STM32 ST-LINK CLI v3.4.0.0
STM32 ST-LINK Command Line Interface
ST-LINK SN: 066EFF525750877267092042
ST-LINK Firmware version: V2J33M25
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Connect Under Reset
Reset mode: Hardware reset
Debug in Low Power mode enabled
Device ID: 0x431
Device flash Size: 512 Kbytes
Device family: STM32F411xC/E
Loading file...
Unable to open file!
Clearly the ST-Link_CLI is succesfully called from inside the IDE, but it somehow cannot digest the .hex file (inside the debug folder) and upload it to the STM32 board.
Even flashing a completely new generated project from CubeMX and setting the options above (including setting it to a .hex file) will not let this toolchain upload it to the board.
Manual code flashing
I have been able to succesfully upload the .HEX file built by TrueStudio via manually uploading it to the STM32 Board with the use of the ST-Link GUI, so I do not think the problem is in the ST-Link itself. I cannot however debug it in this manner, since I need the TrueStudio IDE tools for that and thus need the external tool configuration to work succesfully.
Instead I suspect the issue lies with my own setup, where is somehow is missing a call or has an option set incorrectly. It could also be that the GUI and CLI clients operate in a completely different fashion allowing one to read and upload the file whilst the other cannot, but that seems unreasonable to me.
I am kind of at a loss here however, as I cannot seem to figure out why others can make this work via the provided Atollic documentation and mine is throwing up these errors.
You try to reinvent the wheel using the triangle.
Everything is configured in the TrueStudio:
Just in add the debug configuration and you are done.
What benefits would OpenOCD offer at this point
One essencial : debugging
given how much I have already learned about TrueStudio?
This knowledge (how to configure external tools etc) is rather useless in 99.9999% of circumstances. It is only the configuration of the Eclipse. Not too complex actually needed here.
In regards to my own code, I have not been able to get the ST-Link_CLI to work as an external tool the way I intended, [but I have been able to get the STCubeProgrammer (CLI) to work in the same respective manner as I was attempting to do with the ST-Link].(http://gotland.atollic.com/resources/applicationnotes/AN1801_cubeprogrammer_in_truestudio.pdf).
Seeing as I literally used the same procedure as before but instead specifying the location and executable for the STCubeProgrammer (rather than the ST-Link), I suspect the issue may indeed be the ST-Link CLI (connection to TrueStudio).
It now uploads successfully and immediately after boots me into the debug environment of TrueStudio :)
I simply commented "load" command in the startup script and debugging worked. I only had to load the hex using the st link first.
/# Load the program executable
#load <---//added "#"
I had a problem while deploying code into my STM32F4Nucleo boards using Eclipse and I wanted to share the solution for public benefit.
The problem is that the build process was working however when it comes to deploying the code into the microcontroller the system was stuck, further I was not able to debug the device. The step over and resume buttons were greyed out in the debug perspective.
Later I realized that it was due to the naming of the startup code of the MCU. For example in my case the name was,
startup_stm32f401xe.s
I forgot to capitalize the "s" in the extension of the file. When you rename it as,
startup_stm32f401xe.S
then recompile, both debugging and the code deployment issue was solved.
Just FYI,
Bests
Another way of doing so is modifying which file extensions are recognized as source files which then get compiled and linked. You can do so here on the workspace level:
or under project settings under C/C++ General -> File Types if you prefer to do so only for specific project(s).
An "Errors exist in the active configuration of project X. Proceed with launch?" dialog appears while debugging code in Eclipse. Hitting the "Proceed" button results in successful debugging. There are no apparent errors with the launch configuration. A similar Run Configuration does not generate the error.
This is caused by an invalid path somewhere in your Eclipse project settings. There are a couple common sources for this kind of error.
You're working on a shared (version controlled, copied, etc) project where someone has hardcoded a path that doesn't exist on your machine, or uses an environment variable that you've not set.
Sometimes, you can find the offending path by looking at the full list of Error messages. If not, look in your project file.
The Discovery Options in your project properties has 'Automate discovery of paths and symbols' enabled - but the process is generating an error.
If you're using a version of Eclipse that warns you this option is deprecated, uncheck the option to disable it and fix any includes in 'Preprocessor Include Paths' instead. If not. . .try it anyway.
Depending on your path changes, restart Eclipse and try again.
It starts the executable that was built last before you broke the build. That executable will be older then your source files. The reason you were able to debug is because your line numbers did not change for the code you've debugged - e.g. you may try break in main then introduce a compilation error and move main a couple lines below - the debug will highlight the wrong lines when it stops.
So far the documentation doesn't include the set up of GWT project in IDEA, and my limited google skill can't find the solution. Is it possible?
If you generated your libgdx project using the gdx-setup.jar file, then you should import your project by using the following link: https://github.com/libgdx/libgdx/wiki/Gradle-and-Intellij-IDEA
HTML: View -> Tool Window -> Terminal, in the terminal, make sure you are in the root folder of your project. Then execute gradlew.bat html:superDev (Windows) or ./gradlew html:superDev (Linux, Mac OS X). This will take a while, as your Java code is compiled to Javascript.
Once you see the message The code server is ready, fire up your browser and go to http://localhost:8080/html. This is your app running in the browser! When you change any of your Java code or assets, just click the SuperDev refresh button while you are on the site and the server will recompile your code and reload the page! To kill the process, simply press CTRL + C in the terminal window.
Once this bug in the Gradle tooling API is fixed, we can simplify running the HTML5 by using the Gradle integration. At the moment, the Gradle process will run forever even if canceled.
Also just a heads up, after you have run the gradle command it might say something like this:
The code server is ready.
Next, visit: http://localhost:9876/
Building 91% > :html:superDev
Even though it says 91%, don't worry it will still work, just go here to run it: http://localhost:8080/html/, NOT the url mentioned in the log.
Also to deploy you need to run ./gradlew html:dist to generate production code, you want to copy everything inside ./html/build/dist/ to your server. Running that command produces the code in that directory. https://gamedev.stackexchange.com/a/82588/54396
I was able to make GWT work with libgdx simply by:
downloading (http://www.gwtproject.org/download.html) the GWT SDK,
extracting it,
then in the project structure -> project-name-html -> dependencies,
just press the + and add the extracted GWT directory
A dialog appears and I just unticked all the samples
The "Dependencies Storage Format" needed to be "Intellij IDEA", not Eclipse for this to work for me.
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