[support]

Hi,

No problem, please see the answers to your questions below:

1. 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.
2. 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.

[support]

Hi,

No problem. We have updated the OpenOCD package on our side to include the new definition file.

[support]

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.

[support]

Please make sure you use an unmodified version of the VisualGDB installer with a valid license.

[support]

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.

 

Attachments:

You must be logged in to view attached files.

[support]

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.

 

[support]

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.

 

 

[support]

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​

[support]

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.

[support]

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.

[support]

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.

[support]

Hi,

No problem, we have fixed the issue in the following build:  VisualGDB-5.6.109.4809.msi​

[support]

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.

[support]

Hi,

Thanks for clarifying this. The “$(ProjectDirLinux)6731_OMFV”  path suggestion is definitely wrong. It is likely suggested because VisualGDB checks the variable list before ProjectDirLinux gets assigned (and hence defaults to an empty value). We have added an extra check on our side to avoid suggesting empty variables in paths, although manually replacing the path with /6731_OMV should work.

Either way, we have double-checked the screenshots you provided and found a few inconsistencies:

1. The project path on the Windows machine is n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsc_cmp\projects\rdp.vcxproj. The corresponding project directory on Linux should be /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/projects.
2. The Linux path of bit.cpp you mentioned is /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp.
3. The relative path reported by gcc is ../src/bit/bit.cpp. Given the base directory, it should translate to /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsc_cmp/src/bit/bit.cpp, that doesn’t match the path in the previous step.
   
4. The Windows path computed by VisualGDB when you tried navigating to the file was n:\6731_omfv\SHMUEL\tdp_develop-linux_test\tdp\dsg_cmp\src\bit.cpp. The _test part should not be coming from the project settings shown on the screenshot.
   

Our best guess is that you have multiple projects that use slightly different (although confusingly similar) file names, so you are changing the setting for one project, while building a different project. Hence, the settings in the VisualGDB Project Properties do not appear to take effect.

The easiest way to unwind this would be to remove all projects but one from Solution Explorer, get it working for just one project, and then add the rest of the projects back, one half at a time, and verifying that paths still work. Another option would be to to follow the inconsistencies we pointed out (e.g.the extra /bit part and the _test part). They must be coming from some setting in a different project, and searching the project/settings files for these parts might explain what is going on.

[support]

Hi,

No problem, we will clarify.

The variable $(ProjectDirLinux) was created because i understood that Local directory (windows) and Remote directory (Linux) should point to the same directory where the project file is located.
Since i have $(ProjectDir) that defines automatically the project path to windows and i don’t have such variable for Linux, so i had to create $(ProjectDirLinux).

It generally depends on how you created $(ProjectDirLinux). You mentioned environment variable, so we assumed it’s something defined in Windows environment (configured via Control Panel->System Settings), that would be the same for all projects. If you defined it as a custom per-project variable, it should be fine.

You wrote “the contents of its directory will be copied to $(ProjectDirLinux)” i guess you meant the compiler output (such as obj files)

We meant that according to the last screenshot from your previous post, VisualGDB will copy the *.cpp; *.h; *.hpp; <…> files from $(ProjectDir) to $(ProjectDirLinux) for every project that targets MRS-RDP-LINUX. Depending on how ProjectDirLinux is defined, this may work as expected, or may not work at all.

Either way, you mentioned the following paths of the file:

• Windows path: n:\6731_omfv\SHMUEL\tdp_develop-linux\tdp\dsg_cmp\src\bit.cpp
• Linux path: /6731_omfv/SHMUEL/tdp_develop-linux/tdp/dsg_cmp/src/bit.cpp

You should be able to get everything working by going to the Path Mappings page of VisualGDB Project Properties for rdp.vcxproj and adding the following mapping:

• Windows path: n:\6731_omfv
• Linux path: /6731_omfv

It should cover all the files inside /6731_omfv. You do not need the entry on the Synchronized Directories page, or any other entry. This entry alone should be sufficient to cover all paths.

[Author]

Posts