Forum Replies Created
-
Posts
-
Hi,
Thanks for the detailed screenshots. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2591.msi
Before starting the wizard, please open the View->Other Windows->VisualGDB Diagnostics Console, then open the VisualGDB Package Manager to trigger a full reload of the toolchain list (producing the diagnostic messages in the console). Finally, open the wizard again, reproduce the problem and attach the log from the diagnostic console. This should be sufficient for us to fix this.
Please also let us know if you are creating a new embedded binary project from scratch, or using project templates or any other advanced options.
Hi,
No problem. We should be able to include the device sharing tool in the next major VisualGDB release (please allow 3-6 months until we will have a preview build with this).
If you would like to get it earlier, we could offer it as a paid custom feature (typically 5 takes business days), but if your timing allows, we would advise simply waiting until we deliver it as a part of our regular release schedule.
Regarding the test frameworks, TinyEmbeddedTest is actually designed by us as a minimalistic test framework with minimum possible overhead on embedded devices, so we will more than appreciate your feedback on the issues you encountered and will be happy to make it better. We would appreciate it if you do start a separate thread about that, as it would make it easier for other users to find that discussion.
Hi,
This could be caused by some leftovers from the previous VisualGDB build that could not compute the IntelliSense settings correctly.
Please try deleting the VisualGDBCache and CodeDB directories and reopening the project. If it doesn’t help, please check if the problem persists in a freshly created project (we have quickly checked it with NUCLEO_L432KC and could not find any issues).
Hi,
This could be caused by your library not using the “src” folder format. Please refer to the Arduino library specification for details.
No problem, we can help you figure this out. Please attach the following screenshots:
- Registry editor showing the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Keil\Products\MDK key contents
- The contents of the Keil folder referenced via the registry
- The VisualGDB toolchain selector with the drop-down list open showing the available toolchains
This should help us narrow it down and suggest a fix.
Hi,
You don’t actually need to create a dummy project – simply install our regular ESP32 toolchain and point the hardware register viewer to the registers.xml file from it.
Hi,
Please try closing the solution, deleting the VisualGDBCache and CodeDB folders and then reopening it. If it doesn’t help, please try creating a new project and ensure that the problem doesn’t affect it.
Then compare the .vgdbproj/.vgdbcmake files between the old and the new project – the old project file might contain some hardcoded paths that became invalid as you have moved it to a different machine.
We have published a detailed tutorial showing how to create bootloader projects with MSBuild here: https://visualgdb.com/tutorials/tutorials/arm/bootloader/msbuild/
Hi,
Sorry, this is by design – the files are indeed referenced in-place. If you would like to copy them instead, please try making a copy of the entire project and selecting “Move VS project to the imported project directory”. This will have the same effect – the VS project will end up in the same directory with a separate copy of the source files.
Hi,
It looks like a problem with debug symbols. Please follow this tutorial to diagnose it.
Hi,
Given the low cost of the modern MCU evaluation boards, we would advise simply running the unit tests on the hardware. To make the board available to the build server, we could supply a small tool for “sharing” the boards – you should be able to run it on a machine with one or more boards attached, and then configure the build server to run the tests on those boards remotely.
In order to run the tests without any hardware at all, you would need to refactor your code, introducing an abstraction layer so that most of the common logic can run in a Windows (or Linux) process as well as on the device. Another option would be to modify QEmu to emulate the STM32 peripherals (we use it internally for VisualGDB integration tests), however it would be relatively complex and exposing the evaluation boards to the build server should be much easier.
Hi,
Thanks for the detailed description. Most likely this is caused by some invisible characters near the line breaks that are interpreted differently by VS and by Clang.
If you ever get this problem again, you might be able to reduce it as follows:
- Add a line “void testfunc();” at the beginning of the source file (after #include-s)
- Replace each of the problematic line contents (without touching the area near the ending of the line) with a call to testfunc().
- Confirm that the problem persists.
- Delete all lines between the declaration of testfunc() and the problematic lines, and also all lines after it
- Remove references to your #include-d files.
If the problem can be still reproduced after reducing it to the test code, simply send us the repro file and we will check for the characters causing it and should be able to add a workaround.
