Forum Replies Created
-
Posts
-
Hi,
Normally component_compile_definitions() in the component’s file should work, so most likely the problem you are experiencing is caused by something else (e.g. source is used by a different component, or one of the CMakeLists files was overridden).
If you are not sure, please try reproducing the problem on a freshly created LEDBlink project. If it can be reproduced there, please try re-downloading the toolchain from scratch. If it still doesn’t work as expected, please check if the problem reoccurs when building the project outside VisualGDB and try submitting a bugreport to Espressif.
You can also use VisualGDB’s CMake debugger to step into the the component_compile_definitions() statement and check whether it works.
Hi,
It looks like you are using the regular Embedded Project Wizard that has been replaced by the Advanced ESP-IDF Project Wizard for ESP-IDF devices. Please try using the new advanced wizard instead.
Good to know it works. We suggested checking the peripheral clock in our first reply.
Regarding the registers, unfortunately it is not realistic to manually verify hundreds of registers definitions in hundreds of ST’s devices, hence we have to rely on an automated process of computing them, that has its limitations. If ST released better SVD files with detailed subregister definitions, we would gladly pick them up and use them instead of the header file parser. Please feel free to suggest that to ST.
Thank you for confirming your support status.
It looks like the register address is indeed correct. If the “test” variable has a value of zero after reading the data at 0x40000400, VisualGDB is indeed working as expected and the problem is caused by something else.The bit field definitions inside each register are computed by our BSP release logic based on parsing ST’s header files and do not reflect minor differences between peripheral instances (e.g. TIM3->CR2 vs TIM1->CR2). You can override this by locating the peripheral register definition file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs (see the MCUDefinitionFile element in the stm32.xml file in the project directory) and manually editing the register definitions you would like to change.
Hi,
This could happen if the register addresses were loaded incorrectly, or if the tool used for accessing the device (e.g. OpenOCD) fails to access the memory.
Please try locating one specific register that should be non-zero and verify that its address shown in the Hardware Registers window matches the documentation (or the address in the code).
Then try evaluating “*((int *)0x<address>)” in the Watch window. If you are using OpenOCD, please try running “mon mdw 0x<address>” in the GDB Session window. Then check if the output is still zero and if the OpenOCD window shows any warnings errors.
If the values are still zeroes, please try reading the register programmatically into a volatile variable (e.g. volatile int test = *((int *)0x<address>) and check its value. If it is also zero, the issue is not caused by the debugging logic and the registers do actually have a value of zero (e.g. if you have not enabled the corresponding peripheral’s clock).
Hi,
We have double-checked it and the new package is online. If it doesn’t appear, please try deleting the %LOCALAPPDATA%\VisualGDB\ArduinoPackageCache directory and restart VisualGDB so that it reloads all Arduino package definitions.
Thanks for the update. We have rechecked everything and it looks like the Arduino tools indeed don’t work as expected when having both 1.0.1 and 1.0.3 packages installed.
We have updated our package lists to show the latest 1.0.3 package. Please install it via Tools->VisualGDB->Manage VisualGDB Packages and then remove the older 1.0.1 package via the same window and you should be able to build the projects as expected.
No problem, please try this build: VisualGDB-5.5.1.3261.msi
It will display “[Paused]” in the ARM semihosting console title when the console is paused.
Normally, deleting those files should not be necessary. Generally, the easiest way to troubleshoot it would be to clone our bootloader example from Github, ensure that it works as expected and compare your project to it.
Another way would be to try tracing the MSBuild tasks involved in the building by turning on verbose MSBuild logging (Tools->Options->Projects and Solutions->Build and Run):
- The BuildBootloaderLinkerInputs should run before the Link task
- The <path>.bootldr-o file should be added as an input to the Link task (see step 14 of the tutorial)
- The .link.rsp file for the main application should include the .bootldr-o file and the .bootldr-o file should not be empty (you can check its contents using the arm-eabi-objdump tool).
This looks like some headers or configuration parameters might be missing in the project.
Generally, the best way to get started would be to select “STM32CubeMX Samples” when creating a new project (see this announcement) and let VisualGDB automatically clone one of the numerous examples that come with the STM32 SDKs, so you won’t need to configure anything manually. We do check that each of those examples compiles out-of-the-box without any errors as a part of the automated pre-release tests, so there should not be any complications along the way.
We can also help you understand various VisualGDB settings and their relation to the underlying C/C++ parameters, however unfortunately we are not able to provide help for generic C/C++ issues, or project-specific issues within our regular support (we do offer a paid consulting service with hourly billing in case you prefer personalized help).
Regarding the STM32CubeMX, please see the following detailed tutorial: https://visualgdb.com/tutorials/arm/stm32/cube/
Hi,
The problem you are describing might be caused by the bootloader.bin file being deleted during the clean of the second project (Visual Studio would then show a build error and building the projects again would resolve it). Please follow the instructions in this thread to update the project settings to work around this.
No problem. The ESP-IDF 4.0 introduced some internal changes to the structure of CMake statements used by it, so it took us some time to update VisualGDB so that it could automatically edit them.
Both ESP-IDF 3.3 and 4.0 are now supported by the following build: VisualGDB-5.5.1.3259.msi
Once you install it, the Tools->Manage VisualGDB Packages window will show the new toolchains compatible with ESP-IDF 3.3 and 4.0.
The new build also introduces the new property editing engine that uses schema files instead of hardcoded logic in order to locate and edit framework-specific CMake statements, so we should be able to react faster next time Espressif changes the statement layout again.
Sorry, we have tried reproducing this with a few different setups, but the .filters file was updated correctly each time. Most likely, the problem is caused by some specific combination of settings in a project that was created with an older VisualGDB version and modified manually.
Either way, if the problem does not trigger for newly created projects and does not disrupt your workflow with the existing ones, we would simply advise ignoring it, as it should not have any noticeable effects.
Hi,
Most likely your key is not valid for the latest VisualGDB version. Please use the following page to find out the latest version compatible with your key or to renew it: https://sysprogs.com/splm/mykey
