Forum Replies Created
-
Posts
-
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.
Sorry, we will not be able to review your project. 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. The mechanism for adding header files is the same: Add->New Item->C/C++ Header File. VisualGDB will automatically create the ‘Header Files’ filter in Solution Explorer for CMake targets that have header files.
Please note that as ESP32 projects have the automatic header search option enabled by default (VisualGDB Project Properties -> CMake project settings -> Automatically find header files), the CMakeLists.txt won’t be modified, as all header files from the source directories will get discovered automatically.
It looks like an issue in the STM32 libraries. Please feel free to contact ST support for further clarifications.
The problems you mentioned with STM32 arised from creating a non-relocatable type of project (despite the other type clearly shown in our tutorials) and ignoring the error messages that clearly showed the paths of the files that were not relocated, despite the editing instructions provided by our support. We do our best to make VisualGDB support many different scenarios and platforms and also publish tutorials describing various different setups, however it is beyond our capacity to guarantee that VisualGDB will work when the necessary setup steps shown in our tutorials are not followed.
The problems with ESP8266 you mentioned look like a corruption of a 3rd-party component (ESP8266 core) that is specific to your machine and unfortunately cannot be reproduced on our side (or fixed on the VisualGDB level).
The last STM32 problem you reported is caused by trying to manually build the STM32F3-specific peripheral driver for the STM32H7 device, despite VisualGDB having a clear and automatic system for selecting the drivers and libraries that are compatible with each device type.
We understand that you were looking for something different and wish you the best in finding the tool that will suit your requirements, however it looks this is not something we could offer.
Unfortunately, we could not reproduce the problem you described. Most likely it is caused by a corruption of some software components on your side. Please try installing VisualGDB on another machine and follow our ESP8266 tutorial to create a project.
Most likely, your antivirus is silently blocking the xz archive unpacker (xzdec.exe in the VisualGDB’s directory). Please double-check your antivirus logs.
You can also install the package manually via Tools->VisualGDB->Manage VisualGDB Packages->Install Package from File, although it will still invoke the XZ unpacker.
