Forum Replies Created
-
Posts
-
Hi,
You can use the same techniques that would work for any other IDE or a directly built project. VisualGDB does not change anything from that perspective.
Hi,
When you install a new ESP-ADF instance with VisualGDB, it simply clones the Espressif’s ESP-ADF repository and checks out the selected tag/branch. The v2.3 tag of ESP-ADF still references ESP-IDF v3.3.2, so that’s the version that gets installed when you use VisualGDB (or any other tool) to clone it from Github. ESP-IDF 3.x still requires the old toolchain.
If you are confident that ESP-ADF can work with the newer ESP-IDF, you can replace it manually using the git commands and use it with a newer toolchain, however this is something to do at your own risk. We generally try to provide out-of-the-box support for the SDK versions available as official releases, but if you want to try other combinations, please expect to do some research and troubleshooting, as they may need some adjustment.
If you have managed to successfully use VS code to install a different combination of ESP-IDF and ESP-ADF, please share the complete steps you followed to get this setup working (including the screenshots of each step) and we can help you configure VisualGDB to replicate the same results. Please make sure you follow our problem reporting guidelines, as we are not able to provide any help unless we have the specific steps we can analyze/follow on our side.
Hi,
VisualGDB does not manage it directly. It simply launches the open-source OpenOCD tool that handles the low-level communication with the target.
You might be able to configure OpenOCD to change the reset behavior by editing the OpenOCD script files, however this is something to do at your own risk and it may require extensive research into OpenOCD internals.
If you are looking for an easy out-of-the-box solution, please consider using Segger J-Link instead.
Hi,
This is somewhat tricky due to the way encoding is handled on the VisualGDB side. We might be able to look into supporting it during the next major VisualGDB release, however it would take more than several months.
As a workaround, we would advise creating a wrapper for the external tool that would run the original tool, and then change the encoding of the generated file to UTF-8. As it will be done automatically each time after the tool is invoked, it won’t result in any extra changes in git. From the source control point of view, it will look as if the tool was generating UTF-8 files in the first place.
Hi,
This looks like a device connectivity issue rather than something VisualGDB-specific. Our best advice would be to try using Segger J-Link. It comes with its own fully supported replacement for OpenOCD, that generally works better in many edge cases. VisualGDB supports both OpenOCD and J-Link software, so all the features you previously used will continue working the same way.
Hi,
Yes, please see the following tutorial: https://visualgdb.com/tutorials/arm/openocd/build/
Hi,
We have just received the ESP32-C3 hardware and finished running tests on it. Indeed, using the external JTAG pins doesnt’ seem to work at all. However, the built-in USB-to-JTAG engine works just fine. We have published a tutorial showing how to use it here and also contacted Espressif for clarifications on the external JTAG support.
Update: we just received clarifications from Espressif on this issue. Debugging ESP32-C3 with an external JTAG probe requires additional setups steps described in this thread. However, using the built-in JTAG engine should be much easier.
Hi,
We usually remove the toolchains that have been superseded by bugfix releases (i.e. use the same compiler version) to save space. If the bugfix release is less stable than the original one, it’s likely due to the ESP-IDF version included in it. If this is the case, please try getting the git commit ID of the version that works for you by running the following command in the esp-idf directory of the working toolchain:
git log -n 1
Below is the sample output from it:
commit 1e3638390964c86b0e7ef3af02973b30c58ea1be Merge: 32c63fca9 1e8fca74f Author: Jiang Jiang Jian <jack@espressif.com> Date: Fri Jun 11 05:19:05 2021 +0000 Merge branch 'bugfix/handling_public_action_frame_v4.2' into 'release/v4.2' esp_wifi: Fix SoftAP crash by handling public action frames. See merge request espressif/esp-idf!13927
You can then checkout the same commit into the other toolchain, e.g.:
git checkout 1e3638390964c86b0e7ef3af02973b30c58ea1be
Hi,
No problem and thanks for letting us know. We have fixed the issue in this build: VisualGDB-5.6.5.4230.msi
No problem and thanks for your pull request with adding proper timeout handling to the telnet target.
We have added a new ITargetWithRawPipes interface to VisualGDBExtensibility.dll that should be implemented by the telnet target:
public interface ITargetWithRawPipes : ICustomRemoteTarget { Stream OpenPipeForReading(string path); }VisualGDB will call the OpenPipeForReading() method, supplying it the full path of the pipe on the Linux machine (e.g. /tmp/pipe). The target should open it and return a readable stream that VisualGDB will read from a background thread.
Note that the pipe output can contain arbitrary bytes and not just printable characters, so the target may need special handling to escape/unescape them properly. We highly advise testing it by reading a test file containing all possible 256 byte values.
Thanks for emailing us the detailed repro instructions. We have double-checked everything and confirmed that NRFConnect SDK 1.6.0 was indeed not working out-of-the-box. It turned out, we could not reproduced it initially due to an old value cached in our test environment.
The problem was caused by this commit, removing the deprecated gccarmemb toolchain variant that VisualGDB used due to backward compatibility.
We have updated VisualGDB to use the correct gnuarmemb name: VisualGDB-5.6.5.4230.msi
If you need to build older NRFConnect versions using the old gccarmemb name, you can edit the NRFConnect/GCCToolchainName tag in the %VISUALGDB_DIR%\Rules\RegularExpressions.xml file and simply restart Visual Studio.
Hi,
No problem. We have added panning support for the following build: VisualGDB-5.6.5.4229.msi. You can now hold Shift and drag it with the mouse to move the viewport around.
We could not reproduce the problem with disappearing graphs, although we have found a glitch that could have been causing it. If the problem persists in the new build, please make sure you can reproduce it from scratch and share the repro steps we could follow on our side, so that we could reproduce and fix it.
Thanks for sharing this. VisualGDB 5.6 Beta 4 should set HWREGISTER_LIST_FILE automatically. If you are using an older Beta, it might indeed fail to do so under some circumstances.
Hi,
VisualGDB can display many different windows, depending on what you are doing. You can find detailed description of most of them in our documentation, tutorials and the list of settings.
If VisualGDB is not working as expected, please provide a complete description how to reproduce the issue from scratch per our problem reporting guidelines and we will try to point you to the relevant setting. Please make sure you include the relevant screenshots, as they often contain important information required to pinpoint the issue.
