Forum Replies Created
-
Posts
-
Hi,
You can do that, but it could be easier to use the dedicated “Language Standard” setting. The exact name depends on the project type, but it would also be under Project Properties -> C/C++ -> Advanced.
Thanks for pointing this out. Our RP2350 scripts were ported from the Raspberry Pi’s fork of OpenOCD and did not make it into that build due to a glitch.
That said, look like the OpenOCD developers have fully merged the RP2350 support now, so we have released another OpenOCD update that includes it out-of-the-box without any workaround scripts.
Hi,
Sorry, it is hard to say why a particular project would not work. You can try creating a new similar project from scratch, make sure that it works as expected, and then compare projects side-by-side.
E.g. you can see the exact object files produced by both projects, symbols inside them (using objdump), or compare the verbose logs to see if any compiler arguments are different.
Hi,
Sorry, this doesn’t look like anything specific to VisualGDB or any known issue. Most likely, there is a bug somewhere.
Hi,
You can alternatively try going to VisualGDB Project Properties -> Unit Tests and enabling a checkbox there, but might trigger all kinds of unexpected errors with Make. The GNU Make is very limited compared to CMake, and the Advanced CMake Project Subsystem was designed exactly to bypass the shortcomings of the GNU Make and MSBuild.
We would advise looking through the documentation to get familiar with main concepts. It will take some time to port a non-trivial project, but it will pay off as the project gets more complicated.
Hi,
Unfortunately, we do not see enough demand for Visual Studio-based kernel development anymore. Many company users moved to developing from Linux directly, and hobbyists typically manage to get things done during the trial period, and cannot justify getting a license. Hence, we will only update VisualKernel once our new cross-platform IDE framework is mature enough to support kernel tracing and debugging directly on Linux.
If your team is interested in using VisualKernel with Visual Studio, feel free to contact us from your work email address with a brief description of your project and the features you are interested in, and we can discuss possible options.
Hi,
The GNU Make-based projects are much more limited compared to CMake. You can still create test projects with GNU Make via the VisualGDB Project Wizard, however the test project will have to be separate from the main project, and the Makefile structure will have a lot more duplication compared to CMake.
Sorry about that, a glitch on our side. We recently updated our build distribution system to support CodeVROOM that has separate Windows/Linux/MacOS installers, and it incorrectly renamed the temporary VisualGDB builds to .exe. You can rename the file back to .msi and it should work again. We have also fixed it on our side.
Hi,
Please try deleting %LOCALAPPDATA%\VisualGDB\PackageCatalog.xml. It should reset the cache and get the correct package.
OK, we have done some testing with the example you provided. We couldn’t reproduce the null reference problem, however resetting the device during an active read call would indeed cause the semihosting subsystem to stall.
We have fixed it in this build: VisualGDB-6.0.108.5354.exe
No problem, we have managed to reproduce and fix it. Turns out, the latest SDK had some changes interfering with our previous patches, so we ended up shipping prebuilt tools with external dependencies.
We have rebuilt the package on our side. Feel free to delete the %LOCALAPPDATA%\VisualGDB\PicoSDK\2.1.1-Package folder and create another project via the VisualGDB Project Wizard to re-download the SDK. Once downloaded, both new and old projects should work just fine.
Hi,
The IDF_TOOLS_PATH is indeed set incorrectly due to a backward compatibility issue. However, running idf.py manually should still work.
ESP-IDF uses its own virtual Python environment pointed by IDF_PYTHON_ENV_PATH. Hence, you can run idf.py by replacing the last file in the batch file with this:
%IDF_PYTHON_ENV_PATH%\Scripts\python %IDF_PATH%\tools\idf.py efuse-common-table
Hi,
We have added support for the SDK 2.1.0 a while ago. The 2.1.1 version got added just now.
In general, if you would like to use a version that we have not fully tested yet, you can get one from Git, but you would need to manually figure out the dependencies that are not included in the repository. E.g. you can try getting the new picotool from the VS Code extension, or check if Raspberry Pi maintainers have published a pre-built version.
Long-term, it looks like the packages used by the RP2040 VS Code extension are usable now, so we will eventually switch VisualGDB to download them just like it downloads the Arduino packages, so you won’t need wait for us to repackage anything.
Hi,
Sorry, this looks like the project just crashes in a random location. Most likely there is a bug somewhere that is triggered by something about the new toolchain.
These are two different tracing techniques. To view the last 1000 running lines of code, you would need to use separate J-Trace hardware and have the trace pins properly routed on the board (see this tutorial). Software trace works differently: it patches specific code locations to generate software trace events (ultimately, just write data to a buffer that VisualGDB will decode). So, you would need to think how the program is structured, what code could preempt the main thread, and put tracepoints there to reconstruct what is going on.
