Forum Replies Created
-
Posts
-
Hi,
Different versions of the Raspberry Pi OS come with different Qt versions. Hence, if your application was developed with an older Qt, it may need to be adjusted in order to work on the latest one.
You might be able to get some clues on the Qt forums, as other users upgrading to a newer Qt have likely experienced similar issues.
Thanks, it looks like the problem is somewhere in the logic that writes the new toolchain ID to the project configuration. Please try this build: VisualGDB-5.6.102.4507.msi
It generates much more diagnostic output in that part, so it should help us narrow it down further. Please try attaching an updated log from the diagnostic console (no screenshots/other logs are necessary) and we will try find the root cause.
It’s hard to say what could be causing this behavior. As far as VisualGDB is concerned, the target confirms the setting of a breakpoint, and never reports that it has triggered. If the firmware is running successfully, it could have disabled some debugging functionality, or could have overwritten the memory. The best way to troubleshoot this type of issues is to compare the project against a reference one where the breakpoints do work, and try eliminating the differences between them one by one.
Hi,
Yes, we can confirm that according to the log, the breakpoint appears to be set correctly (the reply to -break-insert contains an actual resolved address). Most likely, the project crashes somewhere else and the breakpoints simply don’t get a chance to trigger.
Hi,
Good to know it works. Normally, the Windows installer will automatically show the administrator prompt during the installation, however some group policy settings or 3rd-party antivirus software might indeed interfere with it. If you have not changed any security-related settings, this could be an indication that some system files got corrupt.
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.
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
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.
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.
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.
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.
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.
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.
