Forum Replies Created
-
Posts
-
Hi,
The log comes from the OpenOCD tool, that is maintained by Espressif, so we do not have much insights into it. You can try downloading OpenOCD from Espressif directly, running it manually per their instructions, and checking if it works. If it fails with the same error, please consider posting on the Espressif’s forum, perhaps they have a better idea of what’s going on.
If OpenOCD works when running it manually, but doesn’t work with VisualGDB, please let us know and we will walk you through getting it to work with VisualGDB as well.
Hi,
This type of error happens when users change multiple settings at the same time, forget what was changed, and end up selecting the settings that don’t make sense in their context. We suggest re-creating the project from scratch because it dramatically reduces the complexity of the whole setup – instead of checking every possible setting that could be causing the problem, you start from scratch, double-check that a handful of options selected in the wizard makes sense, and end up with a working project.
You can then compare that project against the broken one using a diffing tool (e.g. KDiff3) and quickly find out the mismatching setting.
The best way to avoid this type of problems is to change one setting at a time, verify that everything still works, and make frequent commits to your git repository, so that you can easily roll back to the last configuration that worked. We even have a separate page urging our users to follow this practice, but we still get a fair share of inquiries where the project is broken, the user is not sure what exactly they changed, and they are hoping that we can rescue a non-trivial project that we have never seen before.
Regarding this specific error, there isn’t much we can add to the error message: you somehow ended up with a toolchain that doesn’t match your SD card image. We don’t know what exactly you changed to get to this point, so we cannot point you to one specific setting that will undo it. If the newly created project works while this one doesn’t, please try comparing the .vgdbsettings/.vgdbcmake files between them – it should help you find the critical difference. If you can point to a specific XML element in the settings that is different, we can point you to the GUI setting that controls it, but it should be straight-forward in most cases.
Hi,
It could be a bug in a particular OpenOCD version then. You can always revert to the previous version as shown here: https://visualgdb.com/support/oldpackages/
Restoring the previous OpenOCD and doing a full FLASH erase via esptool.py should completely reverse any changes done by the newer OpenOCD.
Hi,
This looks like a known issue of the ESP32 OpenOCD. Please see this thread for details.
In order to flash the application via USB as the thread suggests, you can use the “Program FLASH Memory” command in the context menu in Solution Explorer (you would need the make sure the virtual COM port used for programming has the correct drivers installed).
Hi,
Thanks, we have rechecked the debugging log. Indeed, the optimization done by the ARM compiler prevents VisualKernel from properly intercepting printk() calls. It does work fine on x86 and x64 targets, however not on ARM. We will try to address it in the further releases, but won’t be able to promise anything at this point.
Regarding the kernel building, there was indeed a glitch that invoked an incorrect command line. We have fixed it in this build: VisualKernel-4.0.3.2334.msi
Hi,
Manually generating build scripts with VisualGDB requires a valid license. Please make sure VisualGDB is activated by running VisualGDB.exe /about and entering your activation key there.
Hi,
Sure, if you already have a scatter file, you can specify its location via either VisualGDB Project Properties -> MSBuild Settings -> Linker Script or MSBuild Project Properties -> Linker -> Memory Layout -> Scatter file, and VisualGDB will pass it to the Keil linker. The only limitation is that VisualGDB won’t be able to automatically edit it to add new memories (i.e. the Additional Memories page won’t work).
Hi,
According to this log, VisualGDB tries to run the setup script from ESP-IDF (C:\Users\Mattia Berton\AppData\Local\VisualGDB\Python3\python.exe c:\sysgcc\esp32\esp-idf\v5.0\tools\idf_tools.py install-python-env) and it fails with an error.
Please try running the same script manually. If it fails with the same error, the issue is not on the VisualGDB side and is caused by something else in your system. You can try reaching out to Espressif to see if it’s a common issue with a known workaround. Once you get the script to work outside VisualGDB, it will work with VisualGDB as well.
Hi,
No problem, please see the answers to your questions below:
- VisualKernel intercepts the printk() output by setting breakpoints in the functions responsible for processing of the printk() messages. On some platforms, the optimization level/debug symbol settings would interfere with it. Feel free to attach a gdb log so that we could recheck it.
- The second issue looks like either your JTAG connection is unreliable, or something prevents the chip from responding to the JTAG commands. If you believe the issue is on the VisualKernel side, please try running OpenOCD and gdb manually. If it works outside VisualKernel, we can help you configure VisualKernel to support this setup as well.
Hi,
Thanks for the detailed repro steps. It looks like you are using the ARMClang toolchain that uses Keil-specific scatter files instead of GNU linker scripts.
Unlike the GCC linker scripts that typically come from our BSPs and follow the same structure, the scatter files come from the Keil packs and can have an arbitrary structure, hence VisualGDB cannot edit them fully automatically.
We have updated VisualGDB on our side to show a warning on the External Memories page when using a non-GCC toolchain.
As a workaround, please consider creating a scatter file manually as shown on this page. You can configure the scatter file used by the project via VisualGDB Project Properties -> MSBuild Settings -> Linker Script or MSBuild Project Properties -> Linker -> Memory Layout -> Scatter file.
Hi,
Most likely, the device uses a different USB VID/PID, that is not recognized by VisualGDB. From a quick look at the original .cfg file, it looks like ST recently added the 0483/3754 ID, so that’s likely corresponds to the new device.
Please try replacing the edp.xml and the files in the QuickSetup directory under %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd with the ones from the attached archive, then restart Visual Studio.
Please let us know if it solves the problem, and we will release an updated OpenOCD package with the correct definition files.
OK, we have investigated it further and thankfully it was a trivial bug that we were able to fix.
Turns out, the logic behind the soft_reset_halt command got changed at some point so that it wasn’t waiting for the target to actually halt. We have updated the CC3220SF script to explicitly wait for the halt and it appears to be working now. Feel free to install the latest OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
The call stack you mentioned indicates that part of the project was not loaded correctly. We have tried reproducing this with a basic iMXRT1062 project, however it worked as expected. Most likely, the issue is triggered by some combination of settings you changed previously.
Please try reproducing the problem on a project created from scratch. If it reoccurs, please share the repro steps together with the screenshots per our problem reporting guidelines, and we will gladly investigate this further.
If the problem only happens on a specific project, it might be corrupt. Comparing the settings files against the working project should usually help track down the root cause.
