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

[support]

This could be related to a recently fixed issue. Please try this build: VisualGDB-5.5.7.3686.msi

[support]

Hi,

This actually looks like a bug in the SSH server (LIBSSH2_ERROR_SOCKET_SEND means that the server has unexpectedly closed the connection), so simply updating the SSH server might solve this.

It may not trigger when running commands manually due to the differences between interactive SSH mode (used by regular terminal software) and the command mode (used by VisualGDB) and you might be able to trigger it manually by running “ssh user@host <command>”.

Either way, we can also add a special custom action to upload and run a temporary script instead of just a single command line. If this works, please confirm that creating a script manually, setting chmod +x on it and running it via Custom Shortcuts) works. If it does, we can add support for uploading and running temporary scripts from the VisualGDB GUI (it will include substitution of variables like $(TargetPath) in the script contents).

[support]

Hi,

Good to know it works. We tried reproducing the issue by running different combinations of building, configuring, reloading and transferring long lists of files, however we could not trigger the behavior you described.

Given the issue you reported in the other thread, our best guess is that some combination of SSH actions triggers some unexpected behavior in the SSH server, and VisualGDB does not fully recover from it. Unfortunately, it’s hard to pinpoint this without further diagnostic logs.

If using SysprogsSync solves the issue, we would advise keeping it, since it’s generally much faster and more reliable than other synchronization methods.

Either way, we added more diagnostic logging to this build: VisualGDB-5.5.7.3685.msi. If you encounter the problem again, please try enabling View->Other Windows->VisualGDB Diagnostics Console, reproduce the error and share both the diagnostic console log and the custom action log. It should help pinpoint the cause of the error.

[support]

Hi,

This could be caused by an incompatible ESP-IDF/toolchain combination. Please make sure you use the ESP-IDF bundled with our toolchain as described here.

[support]

This looks like a problem with the ESP-IDF build tools and not something specific to VisualGDB.

Please follow our ESP32 troubleshooting guide to diagnose this further.

[support]

Indeed, VisualGDB does not read folder overrides from tools.ini and uses the default folder location. You can find out the paths used by VisualGDB by enabling the diagnostic output in View->Other Windows->VisualGDB Diagnostic Console and then opening Tools->VisualGDB->Manage VisualGDB Packages.

You can also try posting your tools.ini file and the exact path where the STM32F7xx_DFP package got installed here and we will try to update VisualGDB to handle it correctly.

Regarding semihosting, please try enabling the VisualGDB’s Advanced Semihosting framework via VisualGDB Project Properties -> Embedded Frameworks. It works much faster than the regular semihosting and does not require stopping the target to handle the output.

[support]

Thanks for pointing this out. This would fix the build, however it will remove the reference to the syscall implementations, so if the program was relying on them, it may not link anymore.

Instead, we recommend clicking the “regenerate MCU files” button on the first page of VisualGDB Project Properties. It will rebuild all the .props files based on the currently selected toolchain and will ensure that all internal variables referenced by the project (such as com.sysprogs.toolchainoptions.arm.syscallspecs) are properly defined.

We also advise updating to VisualGDB 5.5 (currently in preview). It contains extra checks for undefined internal variables and assigns the default values to them in every context, so this problem should not happen anymore.

[support]

No problem, we can investigate it. Do you mind attaching an updated build log so that we could retest it on our side?

Edit:  you can also try running the following command yourself:

VisualGDB.exe /scanlog [build log file]

It will run every line of the build log through VisualGDB’s build message regexes and will display a detailed timing report.

[Author]

Posts