[support]

No problem. This looks like a bug triggered by a combination of the “indent braces” style, disabled auto-pairing of brackets, and disabled auto-reformatting of statements. Since this combination of settings is very rare, indeed it was not covered by our tests.

We have fixed it in the following build: VisualGDB-5.5.7.3703.msi

Either way, you can disable VisualGDB’s code formatting logic if you switch from Clang IntelliSense to the regular VS IntelliSense (only works with projects based on VC++). You can find a detailed description of supported scenarios here: https://visualgdb.com/documentation/intellisense/.

You can also find a searchable list of all VisualGDB settings automatically updated from the latest VisualGDB build here: https://visualgdb.com/settings/

 

[support]

Hi,

No problem, please try this build: VisualGDB-5.5.7.3701.msi

[support]

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

[support]

Hi,

No problem, we have reproduced and fixed the issue in this build: VisualGDB-5.5.7.3700.msi

[support]

Good to know it works. In case anyone else encounters the problem, you can configure the root source folder uploaded by VisualGDB as a part of the build via VisualGDB Project Properties -> Project Settings -> File Synchronization or define additional directories to transfer via VisualGDB Project Properties -> Synchronized Directories.

[support]

Hi,

Thanks for your suggestion.

The trouble with the PSoC devices is that they rely on an extremely complicated software framework, and at the same time have relatively few users, compared to mainstream device families like STM32.

We would advise creating a project manually by following our legacy device tutorial.

[support]

Yes, the Embedded edition supports these frameworks.

However, please be advised that both ESP-IDF and ESP-ADF are very complex frameworks maintained by Espressif and they often don’t work as expected. While VisualGDB includes a convenient GUI layer on top of these frameworks, it inherits all their limitations and bugs. I.e. the VisualGDB license does not cover troubleshooting of issues inside these frameworks, or help with specific projects, as it would cost much more than we charge per license. We strongly advise trying out multiple sample projects with these frameworks during the evaluation period, and making sure you are happy with their reliability and quality.

[support]

Hi,

The easiest way to do this would be to use Embedded Quick Debug.

[support]

Hi,

According to our records, your support period has expired. In order to continue receiving support, please renew your key here: https://sysprogs.com/splm/mykey

[support]

No problem and thanks for letting us know. If you encounter any further issues, feel free to start another thread and we will be happy to help.

[support]

Hi,

This appears to be related to the new mechanism of storing object files in subdirectories, that allows having multiple files with the same name in the project.

Please try the following build, it should handle this better: VisualGDB-5.5.7.3693.msi

[support]

Thanks for confirming this. There might be indeed minor differences between STM32H745 and STM32H747 that could be affecting this. E.g. the M4 core might start suspended and may need to be explicitly started by the M7 core.

If you would like to narrow it down, please consider cloning some of the multi-core STM32CubeMX samples for the Nucleo board, rather than using the default LEDBlink example. These samples come directly from ST and should account for differences between the boards.

[support]

Hi,

Sorry, we are not aware of this issue, however we can suggest a possible explanation and a workaround.

The behavior you described could happen if gdb set software breakpoints in some locations in RAM (i.e. placed the ‘breakpoint’ instruction in specific locations in RAM) and then some of the code would overwrite these instructions (e.g. re-initialize RAM from FLASH again).

If this is the case, please consider setting a hardware breakpoint somewhere in the FLASH memory after the RAM got initialized. Hardware breakpoints will not be affected by RAM overwriting, and once the breakpoint is triggered, gdb will automatically re-insert the RAM breakpoints, repairing the ones that got broken.

If it doesn’t help, please share more details about your setup:

• How exactly do you restart the program?
• What debug tool (e.g. OpenOCD/J-Link Software) you are using?
• Are the broken breakpoints set in FLASH or RAM?
• Does using the “hbreak” command to force gdb to set a hardware breakpoint change anything?

[support]

Sorry, the LIBSSH2_ERROR_SCP_PROTOCOL error means that the remote target has rejected the file upload, so the problem is not on the VisualGDB side. Based on what you have described, the problem appears intermittent, so some random circumstances may increase its chance of being triggered.

If the target path is a shared folder that is available on Windows anyway, please consider setting up a manual path mapping instead. See the attached screenshot for more details.

 

Attachments:

You must be logged in to view attached files.

[support]

Thanks, it looks like the permissions are indeed OK. Please try the following steps to obtain more diagnostic context:

1. Open View->Other Windows->VisualGDB Diagnostics Console and enable it.
2. Try saving the file again.
3. Check the diagnostics console for any error messages produced while saving the file and post them here.

[Author]

Posts