Forum Replies Created
-
Posts
-
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.
Good to know it works. We have indeed released an updated OpenOCD package recently, although it has passed our pre-release tests and had not triggered the behavior you described.
Generally, if you encounter intermittent errors, it’s almost always worth it to try another computer and another board and then try understanding the differences between the working and non-working setup. Many intermittent problems are often caused by factors outside VisualGDB’s control (e.g. wiring, power, USB connectivity, antivirus, disk corruption, etc) and it’s not something that VisualGDB could easily diagnose.
Yes, please try setting the explicit end of FLASH memory on the Dynamic Analysis page to the address just before the special data block you have in the FLASH. VisualGDB will then treat this special block as it it was placed in a different memory and will place the stubs after the last section in the rest of the FLASH memory.
If it doesn’t work please feel free to share the diagnostic log and we will help you find the right settings.
No problem, please let us know the email address associated with your license so that we could check your support status.
Thanks for the detailed description. Indeed, VisualGDB was not automatically converting backward slashes to forward slashes for source paths in CMake-based ESP-IDF projects. We have reproduced and fixed the issue in the following build: VisualGDB-5.4.105.3141.msi
The current tutorial covers the GNU Make-based ESP-IDF projects, and hence uses the different variable names. We will try to publish another tutorial covering CMake-specific setup steps in the next few weeks.
Hi,
No problem, we can share a few techniques to diagnose this, however it looks like your support period has expired. Please renew your license here (in case you have purchased another key already, please let us know the email associated with it) and we will provide instructions for narrowing this down.
Yes, please try using the Tools->VisualGDB->Manage VisualGDB Packages->Online->Show previous versions checkbox.
Hi,
VisualGDB would require this framework if you are running the embedded profiler, or have real-time watch/other dynamic analysis options enabled via VisualGDB Project Properties -> Dynamic Analysis. Please double-check that the project doesn’t have any dynamic analysis options turned on and that you are starting debugging via the regular Debug->Start New Instance command.
Thanks for clarifying this. Removing the Arduino IDE from the system was not necessary, as the problem is likely caused by the ESP8266 Arduino core that we suggested to delete (if you are not familiar with this term, please see this explanation on StackExchange).
The directory of the core is actually mentioned in the error message you posted, so it should be very straight-forward to locate it.
That said, to reduce the chance of interference from other components you might have installed earlier, please try deleting (or actually first renaming) the entire Arduino packages folder:
C:\Users\Sharon\AppData\Local\Arduino15
This will ensure that there are no leftovers and you should be able to create the project per our tutorial.
Hi,
We have rechecked the LPC1769 memory map and it indeed looks like a bug. The memory size definitions for the legacy NXP devices were taken from the NXP’s product lists and most likely there was an error there at the time when our BSP was generated. As a workaround, please consider creating a copy of the LPC1769_flash.lds file in the project directory (via VisualGDB Project Properties) and patching it in place.
Generally, for NXP devices we would advise using newer device families that are using the MCUXpresso framework (e.g. see this tutorial) so that VisualGDB will automatically import the correct linker scripts, device definitions and examples. The older LPCOpen-based SDKs have considerably lower quality and are no longer maintained, so VisualGDB could have picked up some incorrect definitions from them.
The checksum is specific to certain NXP device families and is indeed not automatically computed by VisualGDB. If you are using VisualGDB with Segger J-Link, it might provide a special command for updating the checksum on-the-fly (please double-check if with Segger support if you are not sure). For stand-alone programming scenarios, NXP recommends doing it manually, sorry. We can help you understand the VisualGDB-driven build process and the underlying tools that could be used to inject the checksum, however unfortunately we will not be adding out-of-the-box support for it as it only affects a small subset of no-longer-maintained devices.
The programming error can be normally diagnosed by clicking the “view details” button or link (depending on the way the message is shown) or via View->Other Windows->VisualGDB Diagnostics Console. It is likely generated by the underlying tool (e.g. Segger J-Link) and examining the tool log should point to the root cause.
