Forum Replies Created
-
Posts
-
Hi,
According to our records, your 30-day trial has expired. In order to keep receiving technical support, please purchase a license.
Hi,
No problem, the non-blocking mode behavior looks like our bug. We have fixed it and updated the semihosting framework.
Please install the latest version via VisualGDB Package Manager.
Hi,
This message means that gdb is unable to parse some data it receives from the gdb server (i.e. the Segger gdb stub). Please try running “set debug remote 1” via the GDB Session window to force gdb to dump all interaction between itself and the segger gdb stub, and then try submiting that log to the Segger support. They might be able to tell what is going on.
Hi,
Thanks for the update. The call stack looks like the main thread is waiting for some other window running on a different thread, and does not appear like anything related to VisualGDB.
If limiting the comment lines to 5000 works, VisualGDB could have been incorrectly computing some comment block sizes (we’ve never seen any comment blocks that large in the ESP-IDF codebase), although we could never reproduce this on our side. If you could nail it down to a specific place in the code that triggers the problem, we should be able to investigate it further, otherwise the workaround with limiting the line count should a viable solution.
Hi,
Please let us know the email associated with your license key so that we could verify your support status.
Hi,
Sorry, as the Advanced CMake projects are incompatible with the regular VC++ projects, the VS IntelliSense won’t work for them, hence the Clang IntelliSense is the only option.
Please feel free to let us know if the Clang IntelliSense doesn’t handle some specific cases – we might be able to resolve this. We are also working on an experimental engine build based on the latest Clang 6.0 that improves compatibility with the latest C++ features.
Hi,
No problem, we can help you nail it down. First of all, what exact timings do you mean and how do you measure them?
Second of all, could you confirm that the WriteToFastSemihostingChannel() function is invoked when you call printf()? If yes, does calling it explicitly instead of printf() also result in slow operation?
Finally, do you get the same behavior if you throttle the printf() output (e.g. sleep for 100 msec between each call)? If not, the fast semihosting buffer might be overflowing and delaying the CPU until VisualGDB reads its contents. If this is the case, please ensure you are not using USB virtualization as it significantly reduces the semihosting performance.
Hi,
You might be able to ignore the xauth error (unless you are relying on X11 connection forwarding). The ‘file not found’ issue could be tricker. It would mean that the OpenSSH server confirms the file upload, but doesn’t actually upload anything under /tmp.
Please double-check that /tmp exists and is writable from the current user account. As a shortcut, you could also install gdbserver via ‘sudo apt-get install gdbserver’.
Hi,
It looks like VisualGDB is having trouble configuring the remote system to accept your public key.
Normally VisualGDB would open a new session, run the ‘pwd’ command immediately to find out the home directory, append “/.ssh” to it and run the following command:
test -d <SSH directory> || mkdir -m 700 <SSH directory>
If the command fails, VisualGDB would display that it cannot access the SSH directory.
You can work around this by simply unchecking the “setup private key-based authentication” checkbox in the SSH setup window or by double-checking the target directory structure and ensuring that the account you are using with SSH has the <home>/.ssh directory.
Hi,
Sorry, not sure what you meant. Could you please share an error log showing what exactly is broken?
Hi,
Sorry, the profiler is current ARM-only. ESP32 supports a technique similar to our fast semihosting, so long term we should be able to support profiling on ESP32 as well, however we don’t have any specific plans for this yet.
Hi,
Thanks again for checking this. Looks like the main thread’s call stack is missing one more step – right-click on the ntdll frames (and other unnamed ones) and select “Load Symbols”. This will unwind the stack correctly and will display the meaningful information.
Based on your description, it is starting to look like a bug triggered by some combination of display drivers, resolution, etc, so it might be tricky to solve it on our side. You might be able to avoid it by setting the comment size limits via Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Max. following comment lines/Max. preceding comment lines.
Hi,
No problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2268.msi
It adds support for $(SolutionDir) and $(SolutionPath) for ESP-IDF projects (only when built from Visual Studio).
