[support]

Thanks for letting us know. Please feel free to attach a screenshot of the output window showing the incorrect coloring and we might be able to suggest something more specific.

[support]

Hi,

This might be caused by the way STM32H7 devices initialize the secondary core. We have a separate tutorial explaining it.

Please also make sure you are using VisualGDB 5.5 Preview 7 and not v5.4.

If it doesn’t help, please let us know and we will look further into this.

[support]

Hi,

Please see the following page for a detailed overview of supported debug methods: https://visualgdb.com/documentation/debugmethods/#avr

[support]

Hi,

You can download the old packages by setting the “show old packages” checkbox in the VisualGDB Package Manager.

We have detailed instructions on it (including the manual download steps) on this page: https://visualgdb.com/support/oldpackages/

[support]

Thanks for explaining this. We have updated VisualGDB to automatically reset the “Compile As” setting for assembly files in IAR projects. Please try this build: VisualGDB-5.5.7.3690.msi

[support]

We do test toolchain updates with VisualGDB and it should normally work out-of-the-box. Most strange errors like this one happen when trying to apply several changes at the same time and ignoring various error messages, or by modifying the project structure directly, hardcoding the paths that should be normally referenced via variables.

If you often modify the projects manually, please make sure you read this page first. It explains the embedded project structure in detail.

That said, if you can confirm that installing a specific update consistently breaks some functionality, and provide repro steps for us to reproduce the problem on our side, we should be able to fix it.

[support]

We have updated VisualGDB to match the relevant part of the log, however it may still work differently. Please try this build: VisualGDB-5.5.7.3689.msi

 

[support]

Strange. Just for the record, we have tried running VisualGDB /scanlog on the file you attached, but it only took ~100 msec, so the problem must be elsewhere.

Also it’s hard to say whether you are using the regular output, or the advanced output window. Please attach the screenshots of the output window and the settings where you disabled the advanced output (make sure you restart VS after changing the output settings) so that we could see what is going on.

Also please try narrowing down the slowdown, e.g. whether it happens:

• On first build after starting VS or after some time
• With any project, or only a specific project type
• With any amount of output, or only if the build produced large output amounts

Additionally, if you could make a quick screen video showing the problem, we might be able to narrow it down faster.

[support]

It looks like you are comparing ARMCC (version 5) with the MDK IDE against ARMClang (version 6) with VisualGDB. Please note that these are 2 different compilers and ARMClang indeed defines __GNUC__, even if used with MDK IDE. Please make sure you use the same compiler in both cases.

Regarding the import errors, indeed trying to create the imported project file in a location where it already exists will result in an error message. If you would like to overwrite the imported project, please make sure you delete the previous project file before re-importing it into the same location.

The “$$com.sysprogs.bspoptions.primary_memory$$” error would appear if you select GCC on the first page of the Embedded Project Wizard, and then use the Keil toolchain instead (that does not provide this variable). Please do not do this. Instead, please make sure you select the same compiler type on both pages.

[support]

Hi,

Normally, VisualGDB should build the .s files as long as they are included in the project.

If it doesn’t happen, please double-check that the file type is set to “C/C++ compiler” and it is not excluded from building:

If you can confirm that the file type is consistently set incorrectly (e.g. when importing some project), please let us know the steps to reproduce it and we should be able to fix it.

Attachments:

You must be logged in to view attached files.

[support]

No problem, we can try creating it on our side and attaching the binary, however it will take 1-2 business days, as it will go through a different queue.

[support]

Thanks, it looks like VisualGDB does try to use the 1200bps reset, but for some reason it doesn’t work. Unfortunately, we do not have the hardware on our side to retest it, so we would need you to do a few more checks.

Please try creating a basic C# command-line program and replace the main() contents with this:

using (var port = new System.IO.Ports.SerialPort("COMxxx") { BaudRate = 1200 })
{
    port.Open();
    port.Close();
}

Does running this program manually put the board into a programmable state? If not, does sleeping between Open() and Close() ( Thread.Sleep(1000)) change anything?
If not does sending something to the port with setting port.Handshake = System.IO.Ports.Handshake.RequestToSend change anything?

[support]

Hi,

No problem, we can help you. VisualGDB should normally do the 1200 bps reset as well, as long as the Arduino configuration has the “upload.use_1200bps_touch” variable.

Please try enabling the View->Other Windows->VisualGDB Diagnostics Console window before you program the FLASH memory and then check if programming the FLASH adds the “Performing a 1200 bps reset sequence” line there. If not, please attach your CodeModel.json file from the VisualGDB cache directory so that we could see why it did not get enabled.

If the line appears in the log, please try running both VisualGDB and Arduino IDE’s command line manually from a command prompt window and check if they behave differently (e.g. different working directory or different position of quotes is causing problems).

 

[support]

Thanks for confirming this. We have added support for running temporary scripts as custom actions to the following build: VisualGDB-5.5.7.3688.msi

You can create the script actions as shown below:

Edit: the differences between running the command with VisualGDB vs. manually could be caused by either the extra environment VisualGDB specifies (you can find it out via View->Other Windows->VisualGDB Diagnostics Console) or by the fact that VisualGDB runs multiple commands within the same SSH session, while the command-line SSH command reconnects each time you start it. Either way, the new script action should work around it regardless.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please see the following page for a detailed overview of IntelliSense and code formatting settings: https://visualgdb.com/documentation/intellisense/

[Author]

Posts