[support]

Thanks for reporting this. We have fixed the issue in the following build: VisualGDB-5.5.7.3703.msi

[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]

Just wanted to share an update that we have added support for the WICED SDK to the following build: VisualGDB-5.5.7.3700.msi.

You can now create a basic project using the new WICED project wizard.

If you are using PSoC 6, make sure you use the latest OpenOCD package and configure the debug package per attachment.

We will publish a detailed tutorial in the next couple of weeks as well.

Attachments:

You must be logged in to view attached files.

[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 have done some tests with the PSoC6 using the WICED SDK and will be supporting it similar to the recently added nRFConnect SDK support. However, as the PSoC devices are less popular than mainstream families like STM32, the support for them will be somewhat basic, compared to the STM32 devices.

That said, you can always create 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?

[Author]

Posts