I've been using Eclipse with Segger's JLink for a while now to write my FreeRTOS applications. It's all good, until you want to check the state of threads. When you pause execution in debug mode, what you'll see most likely is idle thread. Because that's what embedded systems do for most of the time - they idle. Often when some task dies or hangs, everything else is still working. At least idle task is working. Unless the system experiences hardfault.
So I finally decided to improve my debugging facilities to obtain at least some info on the state of the system. I'll document my findings as I figure things out. This one will be about threads.
Showing posts with label Eclipse. Show all posts
Showing posts with label Eclipse. Show all posts
Debugging STM32 with JLink and Eclipse
Debugging with JLINK
J-Link is a rather nice general-purpose ARM debugger and offers more standardized GDB implementation than the ST-Link. Also, EDU version is priced at about 50 euros, while basic full version is not that much more expensive at about 300 euros. The super-duper Ultra version goes for about 600, or 800 with Ethernet. Since I use it for research and education, non-commercial EDU version suits me just fine. Although it does have some limitations license-wise, it is identical to JLink Base.
J-Link is a rather nice general-purpose ARM debugger and offers more standardized GDB implementation than the ST-Link. Also, EDU version is priced at about 50 euros, while basic full version is not that much more expensive at about 300 euros. The super-duper Ultra version goes for about 600, or 800 with Ethernet. Since I use it for research and education, non-commercial EDU version suits me just fine. Although it does have some limitations license-wise, it is identical to JLink Base.
STM32 + HAL + FreeRTOS Part IV: IDE (Eclipse) setup
Maybe I should've started with this a bit earlier, but IMO getting project to build from Eclipse is pretty straight forward - just import project as a Makefile project. Despite the fact, that it can't resolve some symbols, make is aware of them and compiles just fine.
So, for starters you'll need Eclipse itself, which is available on their downloads page. What you'll need is "Eclipse IDE for C/C++ developers". I have an old Mars2 version, but it shouldn't matter that much.
To run Eclipse, you also need Java Runtime (JRE) for your system available. JRE has to be with the same architecture (x86, x64) as Eclipse itself (and preferably OS).
Once installed and started up, you have to set up your workspace (directory, where it'll store all the project-related data). It does not have to be your projects folder, I prefer to keep it separately from actual code I commit, to avoid cluttering. Existing code can be easily imported afterwards.
Once workspace is set up, all you have to do is import Makefile project by clicking File/New/Makefile project with Existing code. Click Browse... and browse into the directory with our project source code, where the Makefile is located. It should fill project name based on the folder name. Toolchain selection can be left as <none> for now. Click finish and enjoy your project.
It should be able to build as-is now. Open Src/main.c file in project explorer and hit CTRL+B. If you see .hex and .bin file names in output console, you're dandy.
Now there are some issues with unresolved symbols (which annoyingly get reported as bugs). Let's try to fix that.
The following steps configure the CDT build output parser to automatically discover symbols, include paths and compiler settings based on the output produced by the Makefile.
Now do Project/Clean and then rebuild the project, so that Indexer can read the console output and add index everything mentioned there. Most of the warnings should go away now.
You can ignore make errors on performing make clean, it's usually Windows complaining that it can't find .dep directory. It should still clean up build.
Debugging STM32 applications with Eclipse via ST-Link is a bit more convoluted setup, so that will be reviewed some other time.
So, for starters you'll need Eclipse itself, which is available on their downloads page. What you'll need is "Eclipse IDE for C/C++ developers". I have an old Mars2 version, but it shouldn't matter that much.
To run Eclipse, you also need Java Runtime (JRE) for your system available. JRE has to be with the same architecture (x86, x64) as Eclipse itself (and preferably OS).
Once installed and started up, you have to set up your workspace (directory, where it'll store all the project-related data). It does not have to be your projects folder, I prefer to keep it separately from actual code I commit, to avoid cluttering. Existing code can be easily imported afterwards.
Once workspace is set up, all you have to do is import Makefile project by clicking File/New/Makefile project with Existing code. Click Browse... and browse into the directory with our project source code, where the Makefile is located. It should fill project name based on the folder name. Toolchain selection can be left as <none> for now. Click finish and enjoy your project.
It should be able to build as-is now. Open Src/main.c file in project explorer and hit CTRL+B. If you see .hex and .bin file names in output console, you're dandy.
Now there are some issues with unresolved symbols (which annoyingly get reported as bugs). Let's try to fix that.
The following steps configure the CDT build output parser to automatically discover symbols, include paths and compiler settings based on the output produced by the Makefile.
- Right-click on project Project Properties/C/C++/Preprocessor Include Paths,etc./Providers to open configuration window we're interested in
- Click on CDT GCC Build Output Parser and change the compiler command pattern from (gcc)|([gc]\+\+)|(clang) to (.*gcc)|(.*[gc]\+\+) then apply changes.
- Click on CDT Built-in Compiler Settings and replace ${COMMAND} with $toolchain-path\arm-none-eabi-gcc and click Apply. Here $toolchain-path is path to the toolchain binary folder:
# Windows C:\tools\arm-gcc\7-2017-q4-major\bin\arm-none-eabi-gcc ${FLAGS} -E -P -v -dD "${INPUTS}" # Linux ~/tools/arm-gcc/7-2017-q4-major/bin/arm-none-eabi-gcc ${FLAGS} -E -P -v -dD "${INPUTS}"
Now do Project/Clean and then rebuild the project, so that Indexer can read the console output and add index everything mentioned there. Most of the warnings should go away now.
You can ignore make errors on performing make clean, it's usually Windows complaining that it can't find .dep directory. It should still clean up build.
Debugging STM32 applications with Eclipse via ST-Link is a bit more convoluted setup, so that will be reviewed some other time.
Writing firmware for nRF SDK 12.2.0 with GCC and Eclipse Part I: setup
Set up project directory structure.
I prefer and will use one main PROJECT folder as a base folder and do everything within it. E.g. on my windos computer that would be c:\projects\nRF51-project\, under linux I would clone into /home/user/projects/nRF51-project/. Since we are talking GCC + Eclipse here, both are cross-platform and everything can be done relative to the base path.- Install GNU ARM Embedded Toolchain (arm-none-eabi) from their distribution site. Nordic for some reason seems to like 4 series (specifically 4.9.3 as defined in GCC configuration), but I've been running SDK verisons 8 and 10 on toolchain version 5.4.1 just fine. I would recommend installing toolchain in a location which does not contain spaces, dots and other fancy stuff in the path, such as "C:\tools\gnu-arm\4_9_3\" to avoid path and folder name issues. Make sure that installation is added to the system path. To check that it did actually happen, try starting a new command line and then executing:
- Download latest SDK. According to release notes , version 13.0.0 dropped support for nRF51 series, so we are stuck with 12.2.0. Download that and unpack it somewhere, I'll use PROJECT\SDK\12.2.0\ folder for it.
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Subscribe to:
Posts (Atom)