[support]

Hi,

It looks like the instead of passing the breakpoint event to the JTAG debugger, the kernel tries handling it directly. This might also be the cause for kgdboe error you encountered before.

Please try adding the following startup command to VisualKernel Project Properties -> Startup Commands -> Before Connecting to Target:

monitor gdb_breakpoint_override hard

This will force OpenOCD to use hardware breakpoints instead of software breakpoints. Depending on the way exception handling is implemented in this kernel port, it may resolve the issue.

[support]

No problem, please try this build: VisualGDB-5.5.2.3447.msi

[support]

For your reference, VS2017 has been updated multiple times since 2018: https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes

There may be many reasons why VisualGDB is not working on a specific machine (e.g. corrupt installation, broken registry, incompatibility with other packages) and our normal technical support covers troubleshooting them. However, we are only able to offer it to users with active technical support running the latest version of VisualGDB.

[support]

Hi,

Thanks for the very detailed problem description. We have investigated the issue and found out that VisualGDB was ignoring the “deploy as root” option for some cases.

We have fixed it in the following build: VisualGDB-5.5.2.3446.msi

[support]

Hi,

The error you mentioned happens because the imported SVD file does not define sizes for some registers. We have updated VisualGDB to assume 32-bit registers when the size is not specified: VisualGDB-5.5.2.3446.msi

That said, the file you attached to the second message appears broken (it triggered an error about mismatching <peripherals> tag), so it will not get imported despite the fix.

[support]

Thanks for the clarification. It looks like some patches or configuration in the kernel you are using make it incompatible with KGDBoE.

Generally KGDBoE is less reliable than other debug methods as it relies on several assumptions about the network driver implementation that don’t always hold.

If your board has JTAG pins available, using it instead of KGDBoE should result in much more consistent and reliable experience. Let us know if you need help understanding the connectivity issues between gdb and OpenOCD.

[support]

Hi,

We do not deliberately break the old versions of our products, however many external tools that VisualGDB depends on (e.g. Visual Studio itself, various toolchains, frameworks, debugging tools, etc) keep being updated and they do not always retain 100% backward compatibility.

As long as you are using the same versions of all tools and components as you did initially, VisualGDB should continue working. However, trying to use a VisualGDB version released several years ago with the latest Visual Studio updates may indeed lead to unpredictable results.

[support]

Hi,

Thanks for providing the detailed description.

It looks like the KGDBoE-based debug session works. The stop happens inside the entry-common.S file and is likely by design:

[  140315 ms] ~"284\t\tb\tret_slow_syscall\n"
[  140315 ms] *stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x80108504",func="sys_call_table",args=[],file="/home/build/fsl-community-bsp/buildOutput/tmp/work-shared/imx7dsabresd/kernel-source/arch/arm/kernel/entry-common.S",fullname="/home/build/fsl-community-bsp/buildOutput/tmp/work-shared/imx7dsabresd/kernel-source/arch/arm/kernel/entry-common.S",line="284"},thread-id="121",stopped-threads="all"

Normally, VisualKernel would open the entry-common.S file in Visual Studio once that stop happened, however depending on how you imported the kernel into it, it may not know where to locate it. If this is the case, you can setup a manual mapping between the paths reported by gdb (e.g. /home/build/fsl-community-bsp/buildOutput/tmp/work-shared/imx7dsabresd) and the paths on the Windows machine via VisualKernel Project Properties -> Path Mapping.

Regarding JTAG, most likely your firewall is blocking the connection (gdb running on the build machine needs to connect to OpenOCD running on the Windows machine), or the build machine is not able to resolve the Windows machine‘s host name due to missing DNS entries. Please double-check the firewall settings and the gdb log (search the gdb log for “remote” to find out the host/port used by VisualKernel). You can override the “remote” command via VisualKernel Project Properties -> Debug Settings -> Advanced.

[support]

Hi,

It looks like your support period has expired. In order to continue receiving technical support, please renew it here: https://sysprogs.com/splm/mykey

[support]

Sorry, we tried reproducing the problem with your scatter file (we reduced IRAM1 size to 0x4000 and IRAM2 size to 0x8000), but it did work as expected with the following variable:

char g_Test1[0x6000] = {
1, 2, 3
};

It did get placed into IRAM2 and got initialized correctly. Most likely, some other project setting is interfering with this on your side.

If it still doesn’t work for you, please try reproducing the problem on a clean project and share the exact repro steps that we could follow on our side (see our problem reporting guidelines). If we could reproduce the problem in our environment, we should be able to suggest a workaround, or release a hotfix resolving it.

[support]

Hi,

The parametrized tests unfortunately won’t solve the problem, however we are planning to extend our advanced semihosting framework to support reading test data same way  it currently outputs test results. We should be able to give a time estimate on this in the next 1-2 weeks.

[support]

Hi,

VisualGDB would normally use the clang-format engine to format the source code. Clang-format uses its own configuration files that are not 100% in sync with the regular Visual Studio formatting options (although VisualGDB does synchronize the main options).

That said, VisualGDB comes with a graphical editor for the clang-format configuration files, so you can easily tweak the code formatting behavior by clicking the button shown below:

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This might indicate that the KGDBoE module (debugging over Ethernet) is not fully compatible with your target, or it could indicate a symbol problem.

If you could attach a gdb log from the debug session, we should be able to tell what is going on. Please also consider debugging the target via JTAG, as it is generally less fragile.

[support]

Sorry, if the esptool.py doesn’t work, the device or board might be malfunctioning. Please consider posting more details on the Espressif forums and asking whether there is a workaround.

If you could get the underlying tools to work with the device, VisualGDB should be able to work with it as well.

[support]

It looks like due to the differences between Solaris and Linux, the logic responsible for creating a remote terminal is not working. Unfortunately, as Solaris is much less popular than Linux, VisualGDB does not support it.

[Author]

Posts