Forum Replies Created
-
Posts
-
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.
Sorry, that wouldn’t work. You need an ELF file built with relocation records and full debugging symbols.
Hi,
Sorry, this looks like the ELF file you are trying to trace contains some non-standard relocation records, so VisualGDB won’t know how to patch it. We can update VisualGDB to dump the exact address of the relocation record so you could try to adjust the code to avoid it, but it may turn out that there are multiple similar records with no easy fix.
No problem, we will try to explain what is going on.
The problem is most likely related to the TLS versions (protocol used by HTTPS). In order to maintain backward compatibility with VS2008, VisualGDB binaries are built to be compatible with all .Net versions starting from 3.5. However, the actual .Net 3.5 requires the old TLS 1.1 protocol that has been dropped by the latest web server software.
So, as a workaround, VisualGDB uses configuration files (e.g. VisualGDB.exe.config) to explictly request Windows to prefer the newer .Net 4.0 that works with the latest TLS:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0.30319"/> <supportedRuntime version="v2.0.50727"/> </startup> </configuration>
The error would happen if you were using the old VS2008 (that depends on .Net 3.5) or somehow Windows would stop using the latest .Net version and would revert to 3.5. It is difficult to say why exactly it would happen on a particular machine, however we can suggest a few workarounds:
- Try replacing the SessionServer.exe executable in the VisualGDB directory with this version: https://sysprogs.com/files/tmp/SessionServer.exe
- Double-check that the visualgdb.exe.config and SessionServer.exe.config files are present and specify v4.0 before v2.0.
If nothing helps, you can work around it by using a separate forwarder that would fetch the session keys using TLS 1.2 and feed them to VisualGDB. Let us know if you nothing else helps, and we will provide more details.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Update: it looks like you are using a floating license. Please try selecting Help->About VisualGDB->Revert to trial. If this fixes the problem, it will be covered by our support even with an otherwise expired support period.
Well, yes and no. As far as VS code goes, the answer is still a hard no. VS Code is rather limiting in terms of GUI integration, so supporting it would mean competing against a plethora of free alternatives, while being largely limited by the VS code framework, and hence not being much better.
If you know any successful paid extensions to VS Code, it would be interesting to have a look, but if there aren’t many of them, it somewhat proves our point.
The good news is that the cross-platform GUI frameworks have finally caught up, so we have been working on our own cross-platform shell, that supports Windows, Linux and Mac, while being built mostly on the same tech stack as VisualGDB. It will first come out as a separate product focused on a few AI-specific tasks, and will then start gradually receiving functionality from VisualGDB. Stay tuned, the first preview build of the new product is a couple of weeks away!
Sorry for the delay. We have rechecked the logic behind BSP_SOURCE, BSP_EXPLICIT_LOCATION and loading of the regular BSPs, and it looks like the regular BSP loading is not necessary when either one is set:
if((NOT ("${BSP_EXPLICIT_LOCATION}" STREQUAL "")) OR (NOT ("${BSP_SOURCE}" STREQUAL "")) ) set(_load_regular_bsps 0) endif()We have updated the code on our side and will include it in the next VisualGDB update after it passes all tests.
