Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
No problem. We have reproduced and fixed the problem. Please try this build: VisualGDB-5.5.2.3395.msi
November 22, 2019 at 19:30 in reply to: Cancel install/update AVR Boards package won't affect fully #26540support
KeymasterThanks for the repro steps. We have reproduced the problem, however it looks like it’s limited to showing incorrect value in the status bar. Indeed, canceling an Arduino package installation will immediately stop the download, but the Visual Studio’s status bar will only get updated when another component uses it to display the progress.
Due to the relatively low impact of the issue, we will fix it during the next update of the progress-related logic.
November 22, 2019 at 18:30 in reply to: Generating bin file for extra memories is slow for large projects #26539support
KeymasterThanks for the link. We have reproduced the problem. Indeed, when using Internet Explorer (not Edge) to download the temporary builds that don’t go through our CDN system, the extension changes to .man. it should be indeed trivial to fix it, however due to relatively low impact, we will delay it until the upcoming upgrade of our server framework, so that we could fully test it as a part of the post-upgrade tests. If this becomes more annoying, feel free to ping us and we will consider raising the priority for this.
support
KeymasterThe chronometer does show the time since the last event, even if it was of another type. You can double-check it by setting 2 breakpoints inside the LEDBlink loop. If it doesn’t work as expected, please share the repro steps along with the relevant screenshots per our problem reporting guidelines and we will investigate it.
You can also switch the chronometer to show the absolute timestamps (i.e. from the beginning of the session) to minimize confusion.
P.S. If the absolute timestamps don’t make sense, some code inside your project might be resetting the ARM cycle counter that is used by the chronometer. E.g. VisualGDB’s profiler does that to avoid overflows.
support
KeymasterNo worries and thanks for posting the full screenshot. It made it much easier for us to find and point out the cause.
support
KeymasterHi,
Just wanted to share an update that we have added support for embedded code coverage (including Live Coverage) to the following build: VisualGDB-5.5.2.3390.msi
You can enable it via VisualGDB Project Properties -> Code Coverage.
For most accurate results, please consider upgrading to the latest GCC 9.2.1-based ARM toolchain (that is a repackaged version of the official GNUARM toolchain).
support
KeymasterHi,
Looks like you are viewing the installed packages. Please try switching to the “online” view instead.
support
KeymasterSorry, unfortunately we are not able to provide project-specific help as a part of our regular product support. The only advice we can give is to make sure you follow and understand each step of the tutorial mentioned in the previous post. It does explain the “undefined reference” problem and the techniques used to troubleshoot it.
support
KeymasterPlease follow the tutorial below for measuring the time between events on embedded devices: https://visualgdb.com/tutorials/arm/chronometer/
support
KeymasterHi,
The Cortex-A devices are typically used together with Linux and hence require a special Linux toolchain built for the exact distribution/configuration that is running on the target.
We provide toolchains for the most commonly used Cortex-A boards (e.g. Raspberry Pi, Beaglebone). If you are using a different board, please check the board vendor for a cross-toolchain.
If you are looking for a barebone environment (without Linux), please try creating a project manually as shown in this tutorial: https://visualgdb.com/tutorials/arm/legacy/
support
KeymasterYes, please try deleting all the toolchains and installing the one from https://gnutoolchains.com/esp32/.
Then check if you can create, build and debug a new project from scratch. If it doesn’t work please share the details and we will help.
If a new project works, but the existing one doesn’t, you may need to port your project to the new ESP-IDF (the ESP-IDF releases are not 100% backward-compatible). If you are getting errors specific to ESP-IDF API, please consider asking on the ESP32 forum.
support
KeymasterHi,
Sorry, the built-in gdb simulator doesn’t work well for ARM targets and cannot be recommended for any practical scenarios. It is only usable for basic low-level tests (e.g. quickly checking that the ELF file can load into gdb and has the necessary debugging symbols).
support
KeymasterHi,
Yes, please try using the $(TargetDir.forwardslashes)/$(TargetNameWithoutExtension) syntax.
You can disable the regular FLASH programming via the “Program FLASH memory” setting on the Debug Settings page of VisualGDB Project Properties.
support
KeymasterHi,
In order to use ESP-IDF 4.0, please update to VisualGDB 5.5 Preview 1.
Please note that the old ESP32 toolchain based on gcc 5.2 only supports ESP-IDF 3.x. See this page for a full list of supported toolchain/ESP-IDF combinations.
support
KeymasterHi,
No problem, you can always install the previous debug method via Tools->VisualGDB->Manage VisualGDB Packages->Show Old Package Versions.
Generally, the ESP32 tool ecosystem is relatively fragile, so some combinations of toolchain/ESP-IDF/debug package may indeed not work.
If you encounter weird reliability issues, we would advise starting with a basic LEDBlink project using one of the toolchain+ESP-IDF combinations shipped by us (they passed minimal tests on our side) and then comparing the working setup with the one that behaves unreliably. This should help pinpoint the specific parameter that is causing the issues.
-
AuthorPosts