[support]

Hi,

It does look like some sort of a low-level communication issue between OpenOCD and the JTAG probe. If others have reproduced the same problem outside VisualGDB, it may indicate that the Espressif’s OpenOCD port is simply not compatible with this version of J-Link.

Our best advice would be to try one of the debug probes that is fully supported (e.g. Olimex ARM-USB-OCD-H or any other one based on the FT2232 chip). Also if Espressif fixes the issue in the future in their github repository, please feel to let us know and we will be happy to release an updated binary package with the fix.

[support]

Hi,

As of v5.4, most of the windows should automatically pick up the regular VS fonts and colors. If it doesn’t happen, please try attaching the screenshots of both the VisualGDB’s window and a normal VS window having a different font size and we will look into this.

[support]

No problem, we have added a registry setting that fully restores the old behavior for all of the projects on a specific user account.

Please try this build: VisualGDB-5.4.105.3118.msi

Then, set the HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings\BSPFlagsOverridePerConfigurationFlags value in registry (REG_DWORD) to 1, or simply use the attached .reg file.

Please note that both the original change and this fix only affect the logic for generating the mcu.props file, that happens each time you change a setting on the first page of VisualGDB Project Properties and click “Apply”. Hence in order to restore the old behavior, please edit any setting on that page after updating the registry. You can verify that the mcu.props overrides the settings from the .vcxproj file by checking the “Condition” attribute, e.g.:

 <ClCompile>
<Optimization Condition="true">O3</Optimization>
</ClCompile>

The projects that were created with the old VisualGDB version and were never edited with v5.4 do not need to be updated as their mcu.props file still uses the old syntax.

Let us know if you have any further questions/suggestions and we will be happy to help.

Attachments:

You must be logged in to view attached files.

[support]

Sorry about that. There is no need to roll back – we can add a setting to VisualGDB that will allow switching between the old and the new behavior, although the redundancy between the optimization setting in the VS properties and the manually specified flag in the stand-alone project properties may cause further disturbances in the future.

We can also create a small tool that will check the stand-alone projects for the optimization flag and would move it to the correct VS-level property, eliminating the redundancy. Depending on how your projects are structured, running a single tool followed by a command-line build could be viable. If not, we can add the setting described above.

[support]

According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.

Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.

As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.

[support]

The VisualGDB variables work on top of CMake, hence they are not mapped back to it. Otherwise, the project would need to be rebuilt each time you select a different target to debug.

If you could let us know what you are trying  to accomplish, we could try to suggest a workaround.

[support]

Thanks for the description. Looks like some of the changes you made to the project are indeed preventing VisualGDB from being loaded. The latest VisualGDB 5.4 uses a 2-stage mechanism to load itself. First, it starts a very lightweight project loader that checks the opened .vcxproj files for the $(VISUALGDB_DIR) or <Platform>VisualGDB</Platform> text. If not, it assumes the project is not VisualGDB-based and skips loading the rest of VisualGDB. This eliminates any delays when loading non-VisualGDB projects (fully initializing all VisualGDB components does take a few seconds).

VisualGDB projects created via the wizard should contain one of those strings, however if you have manually removed them, indeed the 1-st stage loader will consider this project to be a non-VisualGDB one and will not load the main part of the plugin. Please double-check the .vcxproj file for the strings mentioned above. If they are not present, please try comparing the file to a newly created .vcxproj file and adjust it accordingly.

Let us know if you need further details and we will be happy to help.

[support]

Sorry, this is actually by design. The settings in VisualGDB Project Properties are shared between all CMake targets, while the command-line arguments normally make sense only for a specific targets.

Hence VisualGDB would normally expect you to specify the arguments via the VS Project Properties for each target (i.e. item with the console icon in the Solution Explorer) separately and will automatically substitute them to the $(SelectedCMakeTargetArgs) variable based on the currently selected startup target. This eliminates the need to change the arguments when debugging another target in a multi-target project.

[support]

Hi,

Sorry, this is not supported directly yet, although it is one of the top priority features scheduled for v5.5. Please expect a preview build with this feature around late Spring/early Summer.

[support]

Hi,

No problem, we can help you resolve this.

Adding a Windows configuration to a regular Win32 project is a part of our automated pre-release tests (we have also rechecked it manually now just in case), so the issue is likely caused by some specific setting in your project. If you could share either the project that triggers this, or compare with with a freshly created one and narrow down a specific setting, we should be able to release a hotfix promptly.

[support]

Thanks for the updated log files, looks like we have found the root cause:

Breakpoint update command: +fTest_AcquisitionDelay.py:199

This line should normally contain the full path to the Python file, e.g.:

Breakpoint update command: +f/tmp/VisualGDB/e/projects/temp/LinuxProject17/main.py:3

Please double-check the path mappings via VisualGDB Project Properties -> Path Mapping. The Windows directory containing the .py file should be mapped to the location on the Linux machine where the file is uploaded. As long as this holds, VisualGDB should be able to set handle the breakpoints fully automatically.

 

[support]

Thanks for reporting this, we have fixed the issue in the following build: VisualGDB-5.4.105.3082.msi

[support]

Hi,

This is one of the top items in the queue (we have just released an update to VisualKernel that was another large item), so our current estimate is 1-2 months.

[support]

Sorry, we were not able to reproduce the problem based on your description. If you could reproduce the problem on a newly created LEDBlink project and share it with us, we should be able to reproduce it on our side and fix it.

[support]

Hi,

Please let us know the email associated with your license so that we could check your support status and we will be happy to help you get it to work.

[Author]

Posts