[support]

Thanks for the detailed repro steps. It turns out, a recent change to the Arduino ESP8266 package indeed broke FLASH programming for some targets.

We have added a workaround for this to the following build: VisualGDB-5.5.1.3273.msi

[support]

Please share the exact steps to reproduce the problem from the very beginning (i.e. what exactly to specify on each page of the wizard while creating the project, what exact command to use in order to trigger the problem).

[support]

Hi,

Normally, VisualGDB would launch the Arduino builder that dumps various variables, letting VisualGDB reconstruct the command line. Unfortunately, it is not possible to change it explicitly, however in most of the cases, it should be derived correctly.

Please try checking via Tools->VisualGDB->Manage VisualGDB Packages whether you have multiple versions of the Arduino package installed. If this is the case, please try removing the old package versions. If it still doesn’t help, please let us know and we will investigate this further.

[support]

Sorry, if the 2 projects behave differently, something either about the project structure, or about the project settings is responsible for the difference.

Normally, the line should cause a special type of exception that would be intercepted by VisualGDB’s semihosting logic, however if it doesn’t happen, something interferes with the exception reporting mechanism, preventing VisualGDB from recognizing it.

The best way to diagnose this type or errors would be to start with a working project and slowly change it one step at a time until it is 100% equivalent to the broken one (i.e. uses the same sources, produces a comparable output, etc). If at this point the 2 projects still behave differently, simply use the new project file instead of the old one (although checking it into source control over the old one will likely reveal some differences).

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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).

[support]

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.

[support]

Please try checking under “Updates”. If you have 1.0.1 already installed, 1.0.3 will appear there.

[support]

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.

[support]

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.

[support]

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).

[support]

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/

 

[Author]

Posts