Forum Replies Created
-
Posts
-
Hi,
If you are using OpenOCD, please try adding the mon flash write_image command to the gdb startup commands.
Please let us know the email associated with your license key so that we could check your support status.
Most likely you have accidentally installed a newer version of the ESP-IDF (the pre-release versions are very, very buggy, so we generally recommend using official releases only). Please try deleting and reinstalling the ESP32 toolchain via Tools->VisualGDB->Manage VisualGDB Packages.
Sorry, we still need a specific sequence of steps that could reproduce the problem on our side in order to do anything about it. Generally, C# and C++ use completely different underlying mechanisms in Visual Studio, so it could be triggered by something completely different.
The only other similar issue known to us is that running debug sessions with large amounts of live variables would leak memory due to a bug in VS (about 200 live variables with maximum refresh rate consume all available RAM in about 2-3 hours).
Sorry, the fully supported and easy-to-use way to support excluding files for specific configurations would be to switch to MSBuild. We have specifically designed our MSBuild backend to be fast and support multiple advanced scenarios and this one is definitely one of them.
The alternative procedure with $(filter-out) would involve conditionally removing specific files from the SOURCEFILES variable based on checking the current CONFIG variable, but as it is error-prone and much more fragile, we only recommend doing it if you are familiar with GNU Make internals and would otherwise advise using MSBuild.
Thanks for the update. We have reproduced the problem on our side by manually duplicating some include directories in the .rsp file so that it exceeded the 32KB limit. It looks like a different issue from the 8KB limit that is successfully solved by using the rsp files.
We will review our Nordic BSP and will try to optimize the include paths. As a workaround, please try moving the BSP into a directory with a shorter path (e.g. c:\NordicBSP) and then create a .bsplink file instead of the original directory (e.g. %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x.bsplink) that will contain the full path to the new short directory.
P.S. We have moved the reply from @MystikReasons to a separate thread to avoid confusion.
The latest changes to gcc/gdb mostly do not affect the barebone environments, hence we are not updating our default ARM toolchain regularly. If you are looking for a newer GCC/GDB combination, please try installing the official ARM toolchain. VisualGDB should recognize it out-of-the-box as a drop-in replacement for our default toolchain. The path issue reported by @Kenzi affects all gcc versions, so there should be no difference.
Thanks for the update. It looks like the project is indeed using MSBuild, so the command line length should normally not matter.
Please try reinstalling the ARM toolchain from scratch. If it doesn’t help, please try running the following command from the project directory:
arm-eabi-gcc.exe -v @VisualGDB\Debug\<one of the .gcc.rsp files>
Then, please share the verbose log produced by gcc.
Thanks for the screenshot. It does indeed look like an MSBuild-based project, so the command line length limitation should not trigger here.
That said, MSBuild projects will normally not echo the compiler command line to the build log, so the project might be still somehow configured to use GNU Make.
Could you please share the entire build log (here or via our support form) so that we could check what is going on?
Hi,
Yes, please try using MSBuild instead of GNU Make. Our MSBuild backend automatically uses response files to bypass the command line limitation.
Hi,
VisualGDB 5.1 is very old and is no longer maintained. Please consider updating to v5.4R5. It uses the “.hex” extension by default and also allows overriding it via the IntelHexFileExtension property in the .vcxproj file.
Thanks for sharing this. From our experience, the Espressif team often breaks features in new releases, but then they fix them relatively fast once reported, so it could be worthwhile to leave an inquiry on their forum, or create a bug on Github. But if the slower GNU Make subsystem works for you, that could also be an option.
We are usually indeed able to add workarounds for issues knowing the exact repro steps, however according to our records, the @roguebear’s trial has expired, so we will not be able to offer them any technical support unless they actually purchase a license, sorry.
The sample projects for each device family generally come from the SDKs provided by the device vendor and their amount depends on the popularity of the specific device family. E.g. the STM32 SDKs come with numerous examples and frameworks and are very popular, so VisualGDB offers many examples in the project wizard and encapsulates many frameworks from the SDKs. The Tiva SDK is much simpler and the devices are less popular than STM32, hence the examples offered by VisualGDB are simpler.
The easiest way to get FreeRTOS on Tiva devices would be to download the Tiva C SDK (please use the same version as the VisualGDB’s BSP) and manually add the files from third_party\FreeRTOS\Source to the project (you would need to ensure that only one port instance and one heap instance is selected).
Hi,
The partition table is fully handled by the ESP-IDF itself. VisualGDB simply lets ESP-IDF process it, queries the resulting project structure and renders it in the Solution Explorer, hence it does not control the exact location of the CSV file, or the logic related to it.
Our best advice for locating the partition table file would be to try cloning a sample project with a custom partition table (if ESP-IDF includes one) and checking the build log for partition table-related messages. If nothing helps, please consider checking at the Espressif’s forum – you might be able to get some insights from the team that designed the ESP-IDF there.
