Forum Replies Created
-
Posts
-
Sorry, although we are constantly working on improving the VisualGDB’s capabilities and compatibility with various tools, we are not able to guarantee that every 3rd-party project created with an arbitrary version of the 3rd-party tool will always get 100% imported completely out-of-the-box. VisualGDB does its best at importing the common settings, such as preprocessor macros and include directories, however if you have overridden advanced Keil-specific options, you would need to adjust the imported project manually in order to reflect that. We have indeed published a detailed tutorial explaining this process step-by-step.
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.
Hi,
Please double-check that you are not trying to include STL headers from .h files that are included from plain C files.
If it doesn’t help, please follow the steps on this page to narrow it down to a specific step triggering the problem and we will try to help you. That said, it might be a limitation of the ESP32 toolchain, so it could be worthwhile to check with Espressif whether it’s a known problem.
Good to know it works. If the problem reappears, feel free to reopen the thread and we will investigate.
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.
Good to know it works.
The mbed package system has actually been replaced with the new Advanced Mbed Project Subsystem that works with the latest mbed releases out-of-the-box, supports online libraries and advanced configuration options. You can find a detailed description in this tutorial: https://visualgdb.com/tutorials/arm/mbed/mbed-cli/.
You can also greatly reduce the initial setup time by using shared mbed checkouts. Simply select it on the first page of the wizard and VisualGDB will reuse an existing mbed checkout instead of downloading it from scratch.
Once the initial compilation is done, the subsequent builds of the project should be much faster, as mbed will only rebuild the changed files.
Sorry, it looks like an intermittent problem caused by something about your setup. Unfortunately, it’s not something that VisualGDB could control and hence the only advice we could give is what was already suggested in the previous post.
Thanks for the update. We have rechecked the logic responsible for finding the end of FLASH/RAM and it turned that a recent refactoring on our side broke the scenario you are trying to use.
We have fixed it in this build: VisualGDB-5.4.105.3142.msi
Thanks for playing fair, we really appreciate it.
VisualGDB would indeed normally check that the last 32-bit word before the _estack symbol in the ELF file is writable. This helps detect incorrect/mismatching linker scripts that would otherwise cause hard-to-track errors. You can disable the automatic stack checks via VisualGDB Project Properties -> Embedded Debug Tweaking -> Validate stack pointer when starting debugging.
If your linker script uses a different symbol for the end-of-stack, please consider editing the EndOfStackSymbol element in the .vgdbsettings file to reflect the symbol name from your linker script, so that VisualGDB will check it instead.
No worries. If you encounter any further issues, don’t hesitate to start another thread and we will be happy to help.
If ST did not provide a version of the StdPeriph library for the H7 devices, it means that this library won’t work on the STM32H7 devices.
Please also note that this is something not controlled by VisualGDB and not covered by our technical support. We are also fully booked on consulting projects for the near future.
Please see the other thread you created for clarification: https://sysprogs.com/w/forums/topic/issue-using-the-arduino-blink-examples/
Please see the other thread you created for clarification: https://sysprogs.com/w/forums/topic/issue-using-the-arduino-blink-examples/
Good to know it works. It could have been a network glitch or file system corruption. If you encounter the problem again, please let us know and we will re-investigate it.
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.
