[support]

No problem. We did recheck it with shared projects, so the issue could be caused by something else (e.g. symlinks in the target paths or some particular path syntax).

It could have the same underlying cause as the synchronization problems, but it’s hard to pinpoint anything specific from the observations you are describing.

That said, you can track down the second problem fairly fast as shown below:

1. Isolate a specific file that is not being re-uploaded. Confirm that just changing that one and building file doesn’t get it uploaded.
2. Create a new project with just one file from scratch. Confirm that re-uploading works with the brand new project.
3. Try gradually changing both new and old projects until they are equivalent (e.g. remove some files from the old one, add some files to the new one), rechecking the behavior after each step.

It typically takes less than 10 steps and almost always boils down to a 2-3 settings that were changed together in an unexpected way, and had an unintended side effect. You can also use diffing tools (e.g. KDiff3) to speed up the comparison.

Also, if you wish, we can do it for you via a screen sharing session at our consulting rate. It should take less than an hour to get it all sorted out (you only pay if it worked), however our consulting rate is fairly high and may not pay off depending on your constraints.

[support]

Hi,

Sorry about the build error. We have indeed recently replaced #include <stdarg.h> with #include <linux/stdarg.h>, resolving build issues on some kernels, and did not encounter any problems with the new version.

Can you confirm that changing it back to #include <stdarg.h> in the VisualKernel directory solves the issue? If yes, we can easily add an auto-detection logic for this.

Regarding KDB->KGDB, we added this feature while investigating the KGDBoC timeouts, however it turned out that it should not be normally needed – if you connect GDB to KGDBoC that is stuck in KDB mode, it should automatically detect it and switch, as long as the GDB timeouts are sufficient. We kept the new setting in place in case it helps work around other issues, however it currently only works when the COM port is connected to the Windows machine directly. If you are running GDB on Linux and connecting to /dev/pts/3, you can force the KDB->KGDB switch by running the following command line before connecting gdb:

echo kgdb > /dev/pts/3

This needs to be run on the gdb machine, so the target does not need to be accessible via SSH at this point. If this works better, let us know and we will update the switching logic to run this automatically.

[support]

Hi,

VisualKernel manages the kernel symbols via Kernel Releases – special read-only projects that include all necessary files, IntelliSense index, etc.

Normally, if you select the kernel release via Quick Debug Linux Kernel -> Kernel Symbols for Debugging, it will suggest adding the kernel release project to Solution Explorer first time you stop at some code within the kernel itself.

You can also add the .vkrnlrelease file directly to Solution Explorer by selecting Add->Existing Project and then pointing VisualKernel to the .vkrnlrelease file (see any of the module .sln files for the exact path).

[support]

Hi,

Normally, VisualGDB would invoke ‘chmod +x’ automatically when deploying files. You can double-check it via View->Other Windows->VisualGDB Diagnostics Console.

If you can confirm that it gets invoked intermittently, please try simplifying your setup (i.e. having just 1 project deployed at a time). Does it also fail to run chmod?

If VisualGDB runs chmod successfully, but the target appears to ignore it, it could be a glitch in the SSH server.

Either way, you can configure VisualGDB to run arbitrary commands before debugging via VisualGDB Project Properties -> Custom Debug Steps -> Before Launching Debugger.

[support]

Hi,

The shared projects would normally just copy the list of source files into the actual project referencing them, using the rest of the settings from the main project. We have just rechecked it on a very basic project, and it worked as expected.

You can double-check what is going on by isolating a specific project and a specific source file that does not get coverage, and then:

1. Double-check that the project has the project-level instrumentation enabled (MSBuild Project Properties -> Instrumentation -> Generate Code Coverage Reports).
2. Double-check that the GCC arguments for the source file include the “-coverage” flag. You can check it in the .rsp files (local build) or .msbuild-ninja file (remote build).

Alternatively, if you can reproduce the problem on a minimal project involving 1 shared file, 1 non-shared file and no other overridden settings, feel free to attach it and we will investigate it further.

[support]

Hi,

Semihosting is a mechanism used by the target to send some data (e.g. printf()-like output) to the debugger.

Unless you have changed the code in some way, it should not really be triggering. If you are not sure, please try doing a clean checkout of our PicoHTTPServer demo, and build it from scratch (make sure you also re-download and re-patch the Pico SDK). It should work just fine – we have double-checked it with the latest Pico SDK 1.5.0.

You can also use the Call Stack window in Visual Studio to see why exactly the semihosting gets invoked.

[support]

Hi,

Thanks, this explains it. VisualKernel automatically shows suggestions for COM ports up to COM4 (ttyS0..ttyS3), however as you needed to use ttyS4, you likely entered it manually, with the “/dev/” prefix, confusing the KGDBoC module.

We have updated VisualKernel to explicitly mention the parameters echoed to the parameters file in the error message, to make it easier to diagnose this type of issues. We have also added COM ports up to COM8 (ttyS7) to the selection list.

Feel free to try this build: VisualKernel-4.0.101.2357.msi

[support]

Hi,

It worked just fine in our tests, so most likely you are doing something different.

You can try using the Debug->Attach to Running Embedded Firmware command to attach to it once the problem manifests itself, so that you could see what the device is doing.

[support]

Hi,

Thanks for your clarification. VisualKernel handles KGDBoC as follows:

1. Runs “cat /sys/module/kgdboc/parameters/kgdboc” on the target and compares the output with the contents of the <KgdbocArguments> element in the .vkrnlproj file.
2. If they are different, runs “sh -c “echo <args>” > /sys/module/kgdboc/parameters/kgdboc“. If this command fails, it displays the “cannot configure KGDB” error.

Based on what you are describing, it looks like the KGDBoC parameters configured via VisualKernel GUI are rejected by the kernel and it ends up with KGDBoC disabled. You can verify it very easily by comparing the contents of the <KgdbocArguments> element to”ttyS4,115200“. If it’s different, you can just patch it manually and reopen the solution – VisualKernel will then try to use the KGDBoC configuration you entered manually.

 

 

[support]

Hi,

It looks like due to the low speed of the COM port, gdb times out before it manages to connect to the target. We have updated our KGDBoC tutorial, showing how to increase the timeout.

Also, feel free to try this build [VisualKernel-4.0.101.2354.msi], it will automatically apply increased timeout for KGDBoC connections.

If it doesn’t help, please try adding the “set debug remote 1” command as shown in the tutorial and share the GDB log so that we could recheck what is going on.

[support]

Hi,

The problems with changing the ESP-IDF version and target happen because different ESP-IDF versions/targets are not 100% compatible. Some APIs or build settings are different and VisualGDB cannot automatically translate them between the versions because there are no machine-readable translation rules.

Hence, the recommended way of migrating projects to new targets or ESP-IDF versions is to:

1. Create a new project from scratch, make sure it builds.
2. Switch your existing project to the new ESP-IDF version/target.
3. Manually troubleshoot the remaining issues by comparing the switched project to the project created from scratch.

[support]

No problem and thanks for providing the detailed repro steps so that we were able to reproduce the issue.

[support]

Hi,

The instrumentation-based profiling should work just fine and does not require any special drivers. If the project doesn’t build, you can disable the sampling profiler code via VisualGDB Project Properties -> Embedded Frameworks.

Sampling profiler indeed requires a slight tweak to the STM32 drivers we have, and we can gladly add it if requested by any of our paid users. If you have purchased a license, please let us know the email address associated with it, and we will gladly updated our driver.

[support]

Please contact Espressif directly for all questions about ESP-IDF and other tools provided by them.

[support]

Hi,

This is to be expected. The master branch of ESP-IDF is untested, often doesn’t work on Windows, and may require some tweaking to get working.

Once Espressif resolves these issues and gets confident about the quality, they usually publish it as a stable release, and we release a toolchain that includes it and works out-of-the-box. If you do not want to wait for that and would like to try the pre-release build, you will have to troubleshoot it yourself, sorry.

[Author]

Posts