[support]

Hi,

Sorry, we do not have a toolchain for the 64-bit Raspberry Pi OS. Please consider using a 32-bit Raspberry Pi OS instead, or simply try building the code directly on the target.

 

[support]

Hi,

You can try using an alternate payment processor by following the instructions below:

1. Go to the buy page, locate the edition you would like to purchase, right-click on the corresponding “Buy” button and select “Copy Link”
2. Add “&platform=avangate” to the checkout link copied in the previous step
3. Use the updated link (e.g. https://visualgdb.com/buy/checkout?edition=vgdb_max&platform=avangate) to proceed with the purchase

That said, depending on your location and international regulations, some payment methods may still not be supported. The most versatile payment method that works in every country we are aware of is a major credit card. If this is not an option, please consider finding a local reseller and purchasing through them.

[support]

No problem and good to know it works. We have also updated VisualGDB on our side to suggest the use of the IP address or port when trying to create an SSH connection to ‘localhost’.

[support]

Good to know it works. Also thanks for the suggestion, we will consider adding more checks to the installer in the next VisualGDB releases.

[support]

Thanks for the updated log file. Indeed, VisualGDB is saving the imported toolchain to the location normally used for the Windows toolchains:

Saving newly imported toolchain to C:\Users\709218\AppData\Local\VisualGDB\ToolchainProfiles\localhost\com.sysprogs.imported.arm-linux-gnueabihf-4.8.3__r0...

This happens because the project is configured to connect to localhost via the default SSH port, so VisualGDB treats it as a Linux machine name. In order to workaround it, please consider using “127.0.0.1” instead of “localhost”, or specifying the port explicitly, i.e. “localhost:22”.

That said, we normally advise picking the WSL distro directly in the host selector, rather than using SSH. It will enable the special WSL-specific communication mode, that is faster then SSH.

[support]

Thanks for the screenshot. This VisualGDB build uses the new installation logic that first checks the v170 folder, and if it’s absent – falls back to the v160 folder. Perhaps when you installed VisualGDB, your Visual Studio had the v160 as a leftover from the VS Preview, and the v170 was completely missing (e.g. VC++ workload was not installed)?

Either way, you can try uninstalling VisualGDB completely and installing it again. If the v170 folder is present, VisualGDB should recognize it.

[support]

Thanks, we have narrowed it down further and updated VisualGDB to show a more informative error message. Please try this build: VisualGDB-5.6.102.4508.msi

If the problem persists, please try following the steps below:

1. Enable VisuaGDB Diagnostics Console
2. Open VisualGDB Project Properties and re-import the toolchain. This should be done with the diagnostic console enabled.
3. Make sure the imported toolchain is selected in the VisualGDB Project Properties window. If it shows “no toolchain selected”, please try selecting it manually.
4. If the toolchain doesn’t appear in the list, or if selecting it doesn’t work, please attach the updated diagnostic log. If selecting the toolchain manually solved the problem, feel free to attach a screenshot of the toolchain list and the diagnostic log as well, so that we could check why the automatic selection didn’t happen.

[support]

Hi,

Strange. Could you please share a screenshot of the Help->About VisualGDB window so that we could see what is going on?

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[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

[Author]

Posts