Forum Replies Created
-
Posts
-
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.
Hi,
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
Hi,
This is actually handled by the J-Link GDB stub. VisualGDB launches it when you press F5, and relies on it to handle the low-level debug interaction.
We would advise checking this with Segger support whether the SMP mode is supported for RP2040; if there is a special command or a command-line parameter that enables it, feel free to post it here and we will help you configure VisualGDB to use it.
Hi,
Most likely, you have updated the OpenOCD package to the latest version, and it might contain a bug that would be interfering with the CC3220 debugging.
The easiest way to revert it is to try installing an older OpenOCD build as shown on this page.
If it solves the problem, please let us know the exact OpenOCD versions that work and don’t, and also the exact error output you are getting from OpenOCD, and we will look further into it to see if we can fix it on our side.
We only mentioned the path in step #4 because it was shown on the screenshot. If it’s not relevant anymore, could you please double-check what happens when you try clicking on the message in the VisualGDB Build window? Do you see another error message with the n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\src\bit\bit.cpp path?
If yes, please try using the File->Open command in Visual Studio, and pasting n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp there. If the file cannot be opened, please double-check the path and permissions. If the Windows path of the bit.cpp file is different, the path mapping will need to be updated accordingly.
If you get a different error message, please make sure you expand the details view to see the path, and attach an updated screenshot here.
Hi,
No problem, we have fixed the issue in the following build: VisualGDB-5.6.109.4809.msi
No worries and thanks for the update. If resetting the repository solved the issue, it was likely caused by corrupt VS-level or VisualGDB-level cache (although VisualGDB-level issues are usually visible on the call stack).
Either way, if you weird intermittent behavior again, you can simply try deleting the .vs and .visualgdb subdirectories – it should have the same effect as re-cloning the repository, but you won’t need to do a full rebuild.
