Forum Replies Created
-
Posts
-
Hi,
This might be happening because the FreeRTOS in the ESP8266 SDK is pre-compiled and hence won’t be updated, although there might be some workaround. Either way, please double-check this with Espressif, as they are the vendor of the SDK and know its internals better than we do.
Hi,
We are currently working on the new Advanced Arduino Project Subsystem that will make it possible (and very easy and intuitive) to manage Arduino projects with Visual Studio. If you would like to get notified about the new releases, please consider following us on Twitter.
Hi,
Yes, please edit the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7\15.0 value in registry to point to the VS Professional folder and then uninstall VisualGDB and install it back. This should get VisualGDB to recognize the correct VS instance.
Hi,
No problem, we rechecked the Raspberry Pi support for OpenOCD and can try to clarify this. First of all, please try reading this article – it provides detailed steps with screenshots.
Basically, you would need to build OpenOCD on your Raspberry Pi and run it there (our OpenOCD executable runs on Windows and hence it doesn’t indeed include the drivers that only make sense when running on Raspberry Pi).
On the VisualGDB side, the “custom gdb stub” mode won’t work as it would expect the stub to run on Windows. Instead, please set the following options:
Command <default GDB path> Arguments ——interpreter mi $(TargetPath) Target selection command target remote raspberrypi:<port> Start command continue Please note the double dash before “interpreter mi”.
Hi,
If you have imported the project as an externally built custom project, you can change the main executable path on the Build Settings page of VisualGDB Project Properties.
Hi,
The easiest way would be to use the “custom gdb stub mode” instead of the “full-custom” one. VisualGDB would then automatically configure the GDB arguments (the problem you are describing looks like a missing “–interpreter mi” argument to gdb).
Another option would be replace the OpenOCD binary in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\…openocd\bin with the one you built and manually pick the Rasberry Pi interface file.
It is strange that VisualGDB did not support some JTAG programmers; our OpenOCD build uses default build settings, so all programmers that are normally supported, should work. Feel free to share more details about this and we can help you figure it out.
Also Segger J-Link is recommended only if you are looking for 100% out-of-the-box experience for a wide variety of devices. If you are OK playing around with OpenOCD scripts (or are only using popular devices like STM32), getting an inexpensive Olimex probe should do the job as it works very well with OpenOCD.
Hi,
Please try attaching to your device as shown in this tutorial. It should show what exactly the CPU is doing. Please also use the “Verify memory” button in the GDB Session window to check whether the FLASH memory was programmed correctly.
Hi,
Thanks for confirming this. For MSBuild projects the setting should be under VS Project Properties (not VisualGDB Project Properties) -> Embedded Project -> Generate Binary File.
Hi,
Yes, please let us know your project type (MSBuild or GNU Make) and we can point to the specific location of this setting.
Hi,
Yes, as long as you have the “Generate Binary file” enabled in VisualGDB Project Properties (or VS Project Properties for MSBuild-based projects), VisualGDB should generate .bin files that can be simply programmed to the FLASH memory (offset 0 from the beginning of FLASH).
Hi,
OK, thanks for clarifying this. This indeed looks like the parsing itself is taking a lot of time. If you are opening the project for the first time, this is to be expected – VisualGDB will build various caches and the subsequent operations should take much less time. If anything else is slow beyond the initial delay, please let us know and we can help you pinpoint it.
Hi,
Thanks for pointing this out. We will consider making it more intuitive in one of the next versions.
Hi,
Thanks, this makes sense. Most likely the delay comes from accessing the source code over network. Any remotely located include files that are not a part of the precompiled header would add considerable delays to the parsing due to network latencies. Please try storing the files on the Windows machine and see if this improves performance.
Another way to diagnose this would be commenting out different parts of the main .cpp file and checking how this affects reparse time (e.g. first comment out everything except the #include<> directives at the top, then comment out the lower half of the source file, etc). Please note that each time you modify the preamble (#include<> statements at the beginning of the file), VisualGDB will rebuilt it, showing a greater increase in the reparse time. The next reparse will be much faster.
Hi,
VisualGDB tries to inherit the regular Visual C++ formatting settings under Tools->Options->Text Editor->C/C++, so please double-check that the indentation settings there match your expectations. If VisualGDB still indents the code the wrong way, please attach a screenshot of the relevant VC++ setting and a screenshot of a formatted code fragment and we will try investigating this further.
Hi,
You could try cloning this repo and building it (this might be non-trivial, sorry). Please check all the branches, as the master branch might not be up-to-date.
If you get it to build, we can provide instructions on modifying the scripts to specify the ST-Link v2 serial numbers so that OpenOCD can understand them.
Another option would be to try one of the Olimex debug probes. They are based on the FT2232 chip that basically exposes the low-level JTAG and SWD interfaces directly to OpenOCD, so all the functionality that works with ST-Link will also work with their devices.
