Forum Replies Created
-
Posts
-
This could be related to a recently fixed issue. Please try this build: VisualGDB-5.5.7.3686.msi
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).
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.
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.
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.
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.
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.
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.
Hi,
This feature is very new and requires installing the latest development build. You can download and install it here: VisualGDB-5.5.7.3682.msi
Hi,
It’s hard to say why printf() would not work on a specific device. If you could reproduce the problem with the latest VisualGDB (v5.5), toolchain and the SDK on one of the officially supported Nordic development boards, we should be able to fix it. Otherwise, please consider contacting the device vendor for further help.
Thanks for the update. Looks like the file has the write permissions, but might be inaccessible due to other issues (e.g. bug in the shared folder driver).
Please try editing the same file using the:
- The nano editor via SSH.
- SmarTTY’s editor in the smart terminal mode (File->Open Remote File).
Please let us know whether each of these options works.
It looks like you are testing the entire folder rather than the file shown in the error message.
Please try using a text editor (e.g. nano) to edit exactly the same file that VisualGDB could not access. If it can be saved successfully, it could be a VisualGDB-level issue and we should be able to fix it. If not, it has something to do with the way the folder is mounted and is outside of VisualGDB’s control.
If you want to keep the code base on Windows, please consider selecting it on the “Source code access” page of the wizard. It allows explicitly choosing between keeping the files on Windows and uploading them during build vs. accessing them via SSH vs. other methods.
You can find our the latest version compatible with your key, and also manage renewal an upgrade options on the following page: https://sysprogs.com/splm/mykey
Hi,
Version 5.3R8 is very old and indeed may not work with the latest Python versions. Please try updating to VisualGDB 5.5 Preview 7.
Hi,
It looks like the location where you have the project (that is redacted on the screenshot) is not writable to your Linux user account.
Please double-check the mount point permissions and make sure the Linux user can access it. You can quickly check whether a file is writable by running the following command via SSH:
test -w <file path> && echo "Writable"
If you are not sure how to configure mount points, please try placing the project directly inside the home directory on Linux. It should normally be always writable.
