the Story
I use Symbols to control if a specific piece of Code should be included in the build or not - as most probably everyone working with C/C++ (and others) does. In this particular case I use two symbols, to control if the code running on the Microcontroller is in "Setup"-Mode, or in "EEPROM-Init Mode".
For Both Modes I use Symbols, the Setup Mode Symbol is "SWCONFIG_SETUP" and the EEPROM-Init Symbol is "SWCONFIG_EEPINIT".
The Symbols are defined in the Project Properties of CubeIDE:
The issue is:
both marked lines are skipped in debugging. I'd expect that I could step over/into them when I debug in single step moded, but the debugger just jumps over them, just as if they were disabled and the Symbol SWCONFIG_EEPINIT would not be defined.
I can control that e.g. the code is not executed, because i can not jump into the function with the debugger, and additionaly I can see the Files in the EEPROM were not erased, what would be the purpose of EEP_erase_files();
In the Code both sections are enabled, indicating that the Symbol is defined, otherwise that sections would be greyed out. In an other Code Section, using the #ifdef ... #else ... #endif syntax, the debugger jumps in the greyed out section, indication that it ignores the Symbol.
What I tried to resolve this:
I tried to rebuild/refresh the Index
I deleted the code and re-wrote it.
I deleted the Build Configuration and created it new
I deleted the Symbol in the Project Properties and created it new (using Copy & Paste from the code, to avoid typos)
The Question:
What the heck is going on here? Why is the IDE showing the code section as active, but the Debugger ignores it?
The strange thing is: this workflow allready did it's job!
Solved:
The issue was: i was starting the "Setup" Configuration, not the "SetupEEP" configuration, because for some reason i don't really understand, STM32CubeIDE does not automatically create a Debug configuration, when you create a Build configuration.
I had to create a new Debug Configuration, pointing to the executable in the SetupEEP directory. I just built the "SetupEEP" executable and pressed the debug button, but was not aware, that I started the Debug session with the executable from the "Setup" Build, because i had not created a Debug Configuration for "SetupEEP". This is why the code was omitted: because it was not included in the Build I was running ...
BTW: nice Pitfall, STM!
Related
I am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
I am trying to use the following method to include a project header file:
#include FILE_PATH
Where FILE_PATH is defined as the file to be included.
The project compiles without errors if FILE_PATH is include as:
#define FILE_PATH "hal/micro/config.h"
#include FILE_PATH
But if FILE_PATH is pre-defined as a compiler define option inside the project options, then building the project returns the following error:
Error #13: Expected a file name
The development software being used is Code Composer Studio version 6.
What am I missing here to pre-define the header file path in a project?
Additional Details:
I am in the process of converting a working project from the IAR embedded workbench IDE to Code Composer Studio. The Pre-define NAME (--define, -D) shown in the picture below are mostly identical to how they were in the IAR project.
The pre-define name boxed in red is currently the cause of the error, but this could occur with any of the other defines with file pathnames.
I have tried the suggestion of using the #ifdef statement to at least verify that PLATFORM_HEADER is actually defined and it does seem to be defined. I also checked for typos and there doesn't appear to be any noticeable typos.
The key reason for wanting to go with the pre-defined macro approach is to avoid individually making changes to numerous files affected by this error.
I still have not yet tried a command line compile, since I need to reference the manual on how to do so, but I will try as soon as I figure it out.
#StenSoft wrote:
The IDE does not correctly escape the parameters. You should escape the quotes. You can also try placing PLATFORM_HEADER somewhere in the code and see what the compiler would tell you it sees.
I have an existing C-Project with a pre-written Makefile. I imported the whole thing as a Makefile-Project into Eclipse and it is working fine so far - meaning I can navigate through the code with eclipse and I can build it without problems.
Now I added some Compiler Symbols like NO_ASMto my makefile and updated the code at some points with the according lines of
#ifdef NO_ASM
// Code
#endif
This code is greyed out by my Code-Editor. Now I added the Symbol NO_ASM to
Properties/C/C++ General/Paths and Symbols and rebuilt the indexer - but the according code is still grey. Is there any way to solve this?
Are you sure you added it to all configurations? in all Languages?
You can Try Freshen all files option.
A temporal workaround can something like this:
#ifndef NO_ASM
#define NO_ASM
#endif
i'm trying to do some code in a keyboard driver, a 3rd party software that looks like this can run the command i'm trying to do in a plugin file that compiles alongside the daemon that the command needs to be sent to. the command looks like this.
g15_send_cmd (g15screen_fd,G15DAEMON_MKEYLEDS,mled_state);
here's the code i'm working with and trying to run the command in (it compiles as a plugin with the daemon. in the uncompiled source it's
"g15daemon/plugin/g15_plugin_uinput.c"
the file that defines the command is in
(link)
"g15daemon/libg15daemon_client/g15daemon_clinet.h"
whereas with the g15macro (3rd software) is run from outside the daemon for various reasons i don't want to (and pretty much can't) use it, one being speed of execution of commands when keys are pressed.
so the program compiles like this without error it seems. but if the code i specified above activates, the driver(daemon) crashes giving
g15daemon: symbol lookup error:
/usr/lib/g15daemon/1.9.5.3/plugins/g15plugin_uinput.so: undefined
symbol: g15_send_cmd
what did i do wrong or what am i missing here? (and i'm sorry if the code in the plugin file is ugly down by that switch command, but i didn't know how to do any better since i don't know C much at all, all i have behind me are Py and C#)
Edit: the solution was given
but i don't know how to add a linker flag, also since it links to a part of the program being compiled will it even work?
You forgot to link your plugin with g15daemon_client library. The simple way to fix it is to add -lg15daemon_client to the linker flags.
I'm using eclipse to work on some c code and it is not indexing code inside conditional compilation blocks like this:
#ifdef USE_FEATURE_A
int feature_a(...) {
some = code(here);
}
#endif
How can I get eclipse to index the feature_a function?
You could tell eclipse that USE_FEATURE_A is defined. Open your project properties and go to the "C/C++ General->Paths and Symbols" page, under the "Symbols" tab click the "Add" button and put USE_FEATURE_A in the name feild and click OK.
Note: this will cause it not to index any #else sides to your preprocessor stuff... so unless they are all like the one in question you can't AFAIK, but if they are they you're good. (Eclipse contains a C preprocessor that it uses to analyize your code all the stuff above does is essentially the same as adding -DUSE_FEATURE_A to your command line so Eclipse's preprocessor will behave differently from the one in your compiler)
This is an easier and in my opinion more elegant solution to the one selected as the solution:
If someone has the same problem (as I had), this can (now?) easily be solved by going to Window->Preference->C/C++/Indexer and enable "Index all header variants".
Then click Project->C/C++ Indexer->rebuild and clean and build your project. This should resolve all error originating from preprocessor commands.
For what it's worth, getting eclipse to parse conditionally compiled code is much harder to do than would appear at first glance. I found a paper on by IBM from 2007 where they said they will prioritize for the "next release".
Handling Conditional Compilation in CDT's Core
I had this same problem, but the code conditionally eliminated by preprocessing was perfectly valid c code and I wanted it formatted... This was my solution:
1) Global find/replace of #if to #JUNKif
2) Ctrl-Shift-F to reformat the source
3) Another global find/replace of #JUNKif to #if
One way to index code under flag in Eclipse(Kepler) c/c++Editor.
You can enable the compilation flags in Eclipse editor so that code under them can be indexed.
Properties > Preprocessor Include Paths > CDT User settings Entries
Click on ADD and add the Preprocessor Macro and you can specify its value.
Best way I guess is to use the Indexer option : Project Properties>C/C++ General>Indexer.
You can choose Enable project specific settings
I prefer choosing "Use active build configuration" so that all files which are actually built in the project are indexed.
Anyhow you can also choose to index all files in the project even if they are not included in the build ...