Forum Replies Created
-
Posts
-
Hi,
Please try clicking on “Debug using” and then select “USB Devices”. It should recognize your USB-to-COM bridge and let you select it there.
Hi,
STM32 devices should normally include the “Fixed stack/heap” framework. Are you using a custom project or an mbed-based project?
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.17.1957.msi
It will show detailed information on toolchain selection logic via View->Other Windows->VisualGDB Diagnostics Console. Please share the output from that window and we should be able to fix this.
Hi,
Please find the answers to your questions below:
1) The mbed codebase is very volatile, so workarounds that worked with the latest version supported by us may not work with the latest one. We only recommend using the generator if you are OK resolving this type of issues (or getting paid out-of-schedule BSPs from us if you prefer).
The hardware register definitions use a different format than ARM SVD (providing higher-level detail). VisualGDB can automatically convert SVD to its internal XML format as well, however the STM32 definitions are based on parsing the STM32 header files as the provide more details. If your MCU definition file is not recognized, please ensure that the <MCU> element in BSP.XML refers to it via the <MCUDefinitionFile> element.
2) The specs-related settings look the same as for our regular toolchain, so it’s hard to say why they would behave differently. Please try checking the exact gcc command line VisualGDB uses (for Makefile projects it’s displayed by default, for MSBuild projects is shown after you increase the build log verbosity). Does the command line make sense? Does manually adding the -L<specs directory> to the command line help? Is the command line different from the one used by your previous build method (e.g. is it missing some extra arguments)? If you are not sure, please post the gcc command line from VisualGDB build, the gcc command line from your current build system and the error messages shown by VisualGDB.
5) Please try following this tutorial. It provides an example of importing a project with generating a VisualGDB Makefile.
Hi,
The “Fixed stack and heap” is only available on BSPs with linker scripts are generated by VisualGDB. If you are using a different BSP, you would need to edit the linker script manually (the exact steps depend on the device type) and also specify the stack bounds on the Dynamic Analysis page so that VisualGDB could verify it.
Hi,
If the files are referenced by the gpdsc file, it could be our bug. Please feel free to attach the generated gpdsc file (and files copied by STM32CubeMX) and we could quickly investigate whether this is something we could fix.
Hi,
ESP8266 supports only one hardware breakpoint. If you would like to set more breakpoints, please try moving some of your functions to RAM by declaring them with ICACHE_FLASH_ATTR.
If you don’t want to use the gdb stub, simply disable the call to gdbstub_init().
Regarding the empty com port list, please try attaching a screenshot of this so that we could see what is going on.
Hi,
Sorry, avrdude unfortunately doesn’t support debugging. Our best advice would be to try patching AVaRICE to add support for your device (it conveniently stores device descriptions in a single table in the source code), however we cannot guarantee that this would work.
Hi,
Switching FLASH mode to “DIO” likely did the trick.
Regarding the breakpoint issue, please attach a full GDB log as shown here so that we could help you diagnose this.
Hi,
We haven’t tested VisualGDB with LL projects yet, however this looks like the GPDSC file references some sources that were not copied by the STM32CubeMX tool. You could check this by examining the gpdsc file (or we could check this for you if you could attach the screenshots of your STM32CubeMX settings). If it appears that STM32CubeMX indeed doesn’t copy the files, please file a bug report with ST. If the files are copied to a different location or a named differently, please let us know and we will add a workaround.
Hi,
No problem, we have a detailed tutorial explaining how to use the dynamic analysis to verify the stack size: https://visualgdb.com/tutorials/arm/stack/
The settings should be pretty straight-forward (source/target directories, transfer masks), so it’s hard to tell anything beyond that without knowing more details. Please try attaching a screenshot of your transfer settings and also the path of the XML file on the Windows machine and we will try to suggest what could be wrong.
Hi,
No problem, please find the answers to your questions below:
1) You can build a custom BSP with your own mbed version by using our open-source BSP generator. However as the mbed internals are rapidly changing, it may not work out-of-the-box with every version you would like to try, so you may need to adjust it accordingly (we periodically refresh it to support the latest mbed releases, but trying it with any other version is at your own risk).
2) This could be caused by a typo in toolchain.xml. Please post the contents of your toolchain.xml and the generated mbed.xml and mbed.mak and we walk you through resolving this.
3) Looks like this indeed broken for GNU Make. Please try this build: VisualGDB-5.3.17.1950.msi
5) VisualGDB can import your projects in 2 modes: generate a managed Makefile for it (that will have VisualGDB-specific structure, so VisualGDB can edit parts of it automatically in response to changing options via GUI) and import it as a generic command-line project (VisualGDB will run the build command line specified by you, but won’t make any assumptions about the project internals). We recommend the first import mode for long-term solutions and the second import mode for experimenting and hacking, hence the memory usage output is only supported in the first one. Let us know if you need more examples.
