Forum Replies Created
-
Posts
-
This looks like a known issue. It should not trigger in v5.4R2, however it would be present in some of the daily builds after it. We are currently refactoring the initialization logic of VisualGDB to make different components initialize on-demand and completely eliminate any delays during Visual Studio startups, so some of the daily builds were indeed buggy.
Please try this one, it has the breakpoint problem fixed: VisualGDB-5.4.103.2958.msi
Sorry, we do not support 8051 devices as they do not have a GCC/GDB-based toolchain and are not as popular as ARM-based devices.
Sorry, this doesn’t look like any known issue. If you could provide the exact repro steps for the problem, we should be able to tell what is going on.
Good to know it works. If you encounter any further issues, don’t hesitate to create another topic and we will be happy to help.
Hi,
The CC2530 device is indeed not supported out-of-the-box as it is not as popular as other devices. As a workaround, please follow our legacy device tutorial to setup a project manually.
It looks like your VisualGDB installation might be corrupt. Please share a screenshot of the Help->About VisualGDB window so that we could see what is going on.
The extensions.hpp file is likely included from a different file.
Please try this build: VisualGDB-5.4.103.2946.msi
Please check if the error is shown when opening one of the .cpp files, not the .hpp file, then switch the Clang IntelliSense Diagnostics Console to Projects view and click the “Save” button:
It will dump the IntelliSense state of all projects to an XML file. Please attach it here (or send it via our support form) and we will help you get this to work.
No problem. Please refer to the STM32 documentation for the description of the instruction sets supported by the STM32 devices and to the GCC documentation (and ARM Cortex core documentation) for differences between Thumb-1 and Thumb-2.
In VisualGDB 5.4R2 and earlier, the settings derived from the CPU definition override the settings in the project properties. We have reversed this behavior in the upcoming R3 (you will be able to override the CPU settings via the regular MSBuild pages), however it should not be critical in this case case the STM32 devices do not support the ARM (non-THUMB) instruction set.
Hi,
The ESP32 debugging is generally less reliable than for ARM devices, so glitches like this one are expected. As it is something caused by the low-level interaction between the ESP32 chip and the Espressif’s port of OpenOCD, please consider asking on the Espressif’s forum. They might be aware of the issue and might be able to suggest some specific workaround.
Most likely, building the project with VisualGDB ends up with an incompatible combination of different Arduino components (e.g. core definitions vs. build tool definitions). The easiest way to sort it out would be to delete the existing packages and let VisualGDB re-download the latest ones.
If you decide to untangle it manually, comparing the command lines will likely show differences between the package search directories used by VisualGDB and the Arduino IDE. You can then edit the directories used by VisualGDB via Tools->VisualGDB->Arduino Settings so that they will match the regular Arduino IDE settings.
If anyone else runs into a similar problem, please feel free to post here. If it turns out that the problem is not specific to a single rare setup, we will add checks to VisualGDB to resolve this automatically.
No problem. We have done more experiments with this and it looks like we should be able to generate solution-level test reports with aggregated information from multiple test projects. However, this will involve non-trivial changes to the VisualGDB test engine that might break existing projects, so we will only be able to add this in the next major release (the very rough estimate for a preview build with this feature would be 3-4 months).
Sorry for the delay. We have updated the VisualGDB logic for generating the test containers on the MSBuild level so that it includes the coverage information from referenced projects.
Please try this build: VisualGDB-5.4.103.2936.msi
Please ensure you enable the test container generation for ALL involved projects (the test project and the referenced libraries):
This will get the coverage to work correctly when running the tests from command line (ensure you use the correct test container with the <CodeCoverageInfo> elements when running tests via command line).
Sorry for the inconvenience. It’s hard to say why the system would end up being unusable; the only explanation we could think about is that some file transfers were not fully completed.
BTW, we are working on an update to VisualKernel that will use our new highly optimized file transfer engine, so it will considerably speed up file and directory transfers when caching kernel symbols.
You can debug the kernel boot if you are using JTAG or VMWare gdb stub by selecting “attach to a crashed/hanging system”. This will bypass any attempts to connect to the target via SSH and will proceed with a low-level connection, even if the kernel has not started yet. Please ensure that you have address space randomization disabled before trying this though as VisualKernel will not be able to detect the load address of the kernel unless it can connect to it via SSH.
