Forum Replies Created
-
Posts
-
Thanks for pointing this out. We have updated the tutorial.
BTW, feel free to try out the new Advanced CMake subsystem for Embedded Projects (VisualGDB-5.5.8.3770.msi). It supports multiple targets per project (i.e. bootloader + main target) and allows referencing target outputs from other targets without the need to modify any files manually.
It will be included in the upcoming v5.5 RC1 and we will publish more documentation on it soon.
Thanks, just one more question then. Did the problem ever happen on a recently started VS instance (i.e. NOT after a long period if inactivity)?
Hi,
One quick question: does the problem always happen after you let Visual Studio instance (or MSBuild) run for a long time idling, and then do a build?
Due to some internal changes in the new toolchains, they are not fully compatible with VisualGDB 5.5 Preview 7. We are running some final tests on them and expect to release the v5.5 RC1 around next week.
Update: you can try our new R7 toolchain. It includes both ESP-IDF 4.1 and 4.2 and works out-of-the-box with the VisualGDB build linked above.
Hi,
As long as you use the TinyEmbeddedTest framework, you can set the “Redirect printf() to Test Output window” option in the Test Framework Properties and the output will then appear under the test results (Show Additional Output link). That said, make sure you don’t have multiple conflicting options enabled (see this page).
Hi,
We have briefly retested the latest ESP-IDF 4.1 with our 8.2.0-r6 toolchain (requires this build: VisualGDB-5.5.8.3769.msi) and it worked out-of-the-box (you need to use the ESP-IDF checkout selector to clone the 4.1 release explicitly).
However, it looks like the 4.2 release is now broken due to unresolved Python dependencies. We will look for a way to ship any extra dependencies together with the toolchain and will publish an update once it works reliably. In the meanwhile, you should be able to replicate the setup on your side by using the toolchain and VisualGDB build mentioned above.
Thanks, we have updated the definitions on our side and will include them in the next release of the OpenOCD package.
Hi,
Please try checking the output window (View->Output) for the complete build log. It should contain more information about the error, explaining what exactly went wrong.
If you are not sure, please share the entire log and we will help you understand it.
P.S. Please consider using MSBuild or Advanced CMake instead of GNU Make. It is much better integrated with the VS GUI and will have a much lower chance of random failures due to misaligned settings.
Thanks, this might be related to a glitch that was recently fixed on our side. Please try this build: VisualGDB-5.5.8.3769.msi
No problem, please see this page for more details.
Hi,
We haven’t tested the tumpa adapter directly, but for the directly supported interfaces, VisualGDB can handle multiple instances automatically. Please try locating the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file and search for Olimex ARM-USB-OCD-H.
You can create a similar entry for tumpa, specifying:
- USB VID/PID/interface
- OpenOCD script file
- OpenOCD command for setting the serial number (should be ftdi_serial, same as for Olimex)
You will also need to update the EDP.XML file (search for Olimex ARM-USB-OCD-H again).
Once you edit the files and restart Visual Studio, Tumpa devices will appear in the “USB Devices” view inside Debug Settings, and VisualGDB will automatically pass the serial number to OpenOCD when it detects multiple instances.
Feel free to attach the edited files here (please pack them into a .zip or .7z file) and we will ship the changes together with the upcoming OpenOCD updates.
No problem, please try this build: VisualGDB-5.5.8.3769.msi
Yes, Quick Debug has its own path mappings stored in the .quickdbg files under %LOCALAPPDATA%\VisualGDB\QuickDebugPresets.
You can edit the Quick Debug path mappings using the path mapping icon in the GDB Session window (item #3).
Hi,
No problem, we will be happy to look into this. Would you be able to share a basic project that reproduces both issues? You can either attach it here as a zip file (make sure you delete the built files), or upload it to an external file sharing service.
Thanks, we have updated VisualGDB to fix the issue: VisualGDB-5.5.8.3753.msi
