Forum Replies Created
-
Posts
-
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.
The ELF file should be generated even if the bin file generation is enabled.
The last error looks like you somehow managed to break the project while attempting to get tracing to work.
If nothing works, please try creating a new simple project for the same device from scratch, and verify that tracing works there. If it does, please try comparing the current project layout against the test project layout, to see if there are any differences that could be interfering.
Hi,
Looks like something is broken with your Python installation. We have rechecked it with the Python 3.11.5 (same version as your log mentions) and it worked just fine.
You can try resetting the Python environment or manually pointing VisualGDB to another Python directory as shown on this page.
Hi,
That would be a bit tricky. The fast semihosting driver (that detects the resets) is designed to be interchangeable with several other drivers that can produce similar output, and the console window is also interchangeable with other parts that consume text output. Routing pausing/unpausing through it would make things unnecessarily complicated, and could introduce bugs.
We have made an internal note on it and will look into it next time we do a major redesign of the console logic, but we wouldn’t promise any timeline for it currently.
As for the old contents, they should normally not get cleared at all, but restarting temporarily fills the buffer with zeroes (or bootloader-specific contents) and that could quickly fill the semihosting window, scrolling beyond the previous contents out of view.
Yep. BTW, if you are curious, you can try downloading the build from here: https://sysprogs.com/CodeVROOM/download/.
It is still missing a lot of important parts (e.g. search is completely unimplemented), but it runs on Windows, Linux and Mac, works just fine with insanely huge source folders, and lets you do some basic AI edits, if you are not scared by occasional glitches. The same IDE engine will eventually support running VisualGDB and VisualKernel, but probably not this year.
We will polish a few more things over about a week or so, and will publish the official 0.1 preview. Feel free to post your feedback here; we’ll create a new forum for it after the first preview release, and move it there.
Edit: took longer than expected, but the 0.1 is out. It doesn’t have code suggestions yet, but has functional navigation and search, and the AI-based editing and reviewing is state-of-the-art. It is worth being used side-by-side with your regular IDE for repetitive tasks like multi-spot refactoring, generating code based on other code, etc.
Update: we got more reports of the problem and investigated it further. Turned out, a security update on our server interfered with the legacy non-SSL interface used by the key fetcher.
We have fixed it properly now, so both new and old versions should work just fine.
