[support]

No problem and thanks for your understanding.

Also if you get STM32-specific advice on the ST’s forums and need help mapping it to VisualGDB GUI (e.g. finding the setting for managing include paths, defining preprocessor macros or adding files to the project), feel free to ask us. This is fully covered by our support, although we did our best to make those settings as intuitive as possible.

• This reply was modified 5 years, 6 months ago by support.

[support]

Sorry, our support covers issues specific to our products. It is not possible for us to provide general programming help/personalized introductions to external libraries, devices and frameworks as a part of our product support, as the cost of such a service would greatly exceed what we charge for our licenses.

[support]

No problem, we can help you solve it via our paid consulting services. Please contact our sales to get a quote.

[support]

Sorry, this looks like a question about the STM32 library/framework structure, not something specific to VisualGDB. Please consider posting on the STM32 forums to get help on STM32-specific issues.

[support]

Hi,

It looks like the directory path is invalid:

C:\Projects\MyProject\Bootloader..\bin\

the correct one should be as follows:

C:\Projects\MyProject\Bootloader\..\bin\

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

[Author]

Posts