[support]

Hi,

This would happen if the previous VisualGDB version could not get uninstalled correctly. Please try uninstalling it manually first (see this page for troubleshooting instructions).

Once it is uninstalled, please try installing the latest VisualGDB 5.6 – it should work just fine.

[support]

Hi,

Porting the project from IAR to GCC could be indeed non-trivial due to the differences between the compilers. If you are not familiar with the GCC/IAR internals, we can gladly walk you through the necessary steps via our consulting service. Feel free to contact our sales to get a quote.

If you would like to tackle the problem yourself, we would advise checking the memory layout in the Embedded Memory Explorer (and map files), disassembling the entire images via arm-none-eabi-objdump, or configuring VisualGDB to stop at the entry point (VisualGDB Project Properties -> Embedded Debug Tweaking) and stepping through the startup code step-by-step

[support]

No worries, happy to help.

[support]

Thanks for the update. It looks like your support period has expired a while ago. Please kindly renew it here and we will be happy to help you.

This issue might be also caused by moving to VS2022 without uninstalling the previous VisualGDB version. Please try removing the previous VisualGDB version via Add/Remove programs (you may need to use the Microsoft Install/Uninstall Troubleshooter mentioned on our troubleshooting page) before installing VisualGDB 5.6.

[support]

Hi,

No problem. Please let us know the email address associated with your license key, so that we could link it to your forum profile.

Please also try collecting an installation log as shown on this page and attach it here so that we could see what is going on.

[support]

Hi,

Yes, please make sure you use VisualGDB 5.6. Older versions do not support VS2022.

[support]

As we have explained above, using the ST drivers with a non-ST device would be directly against the ST license terms, and may result in undefined behavior. We do not advise anyone to do it and cannot provide any help with it.

[support]

No problem. We indeed didn’t run all our integration tests on the new build yet, and there was a glitch triggered by objects with exactly 2 gdb-level children. We have fixed it in this build: VisualGDB-5.6.101.4493.msi

Regarding the settings for pretty-printing, it is still a relatively niche option, and the “additional GDB commands” setting fully covers all cases where gdb doesn’t handle it out-of-the-box, so we will keep it this way for now.

[support]

Thank you for your feedback. We will continue monitoring the relative popularity of different device families and will consider directly supporting the ones becoming more popular.

[support]

Thanks for the screenshots. Indeed, the license looks properly loaded and should not be causing this. Could you please double-check whether the problem also happens for other projects, or if it’s specific to this one? Some manual edits to .vgdbsettings and .vcxproj files could cause hard-to-track internal errors.

You can also try using this build: VisualGDB-5.6.101.4492.msi. Please try enabling View->Other Windows->VisualGDB Diagnostics Console before changing the settings, and share the contents of the diagnostics console along with the new error message.

[support]

Hi,

No problem, we have updated VisualGDB to suppress the -var-info-path-expression command for virtual expressions. Please try this build: VisualGDB-5.6.101.4492.msi

Regarding the Python workaround, it looks like something very version-specific, so automating it on the VisualGDB side would likely only work for a very limited number of versions. That said, if applying it manually works, it should be the way to go.

[support]

Hi,

No problem, we have just released an updated Raspberry Pi toolchain: https://gnutoolchains.com/raspberry/

[support]

Hi,

No problem. VisualGDB was relying on the “numchild” field rather than “value” in order to determine whether an expression has children. As it is set to 0 for dynamic expressions, VisualGDB was indeed not showing any children in this case.

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

We have also added a setting under VisualGDB Project Properties -> Advanced GDB Settings -> Expression Evaluation that automatically issues the -enable-pretty-printing command.

[support]

Hi,

This looks like VisualGDB could not get fully activated on that computer. Could you please double-check the Help->About VisualGDB window? Does it show the correct activation information? If yes, does opening the About window before editing any settings solve the problem?

[support]

Hi,

We have just rechecked the sha1-internal.c file on ESP-IDF 4.3.1 and it worked just fine (it was not used by default until we manually disabled mbedtls crypto), so the issue could be specific to a particular project or a particular machine.

Either way, adding the __SYSPROGS_CODESENSE__ wrapper will not affect the build results (this macro is only set by the IntelliSense engine), so it should be safe to do even for library files. Due to the optimization used by VisualGDB to handle large file sets, hiding specific files from IntelliSense would be rather non-trivial, so unless the __SYSPROGS_CODESENSE__ workaround breaks specific functionality, we would advise using it instead.

[Author]

Posts