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

[support]

Hi,

Sorry, the Additional Memories window only works for GCC-based projects, however we can help you configure your Keil-based project to achieve similar results.

Please make sure that the CCM memory in your scatter file (e.g. RW_IRAM2 shown below) is inside the main load region (LR_IROM in the example below). It will ensure that its contents get programmed into the FLASH memory and the Keil startup code copies them into the actual CCMRAM before calling main().

Below is an example of a Keil scatter file defining both RAM and CCMRAM memories:

LR_IROM1 0x08000000 0x00100000 { ; load region size_region
  ER_IROM1 0x08000000 0x00100000 { ; load address = execution address
    *.o (RESET, +First)
    *(InRoot$$Sections)
    .ANY (+RO)
    .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00020000 { ; RW data
    .ANY (+RW +ZI)
  }

  RW_IRAM2 0x10000000 0x00010000 { ; CCM data
    .ANY (CCM_DATA)
  }
}

You can place a specific variable into the CCM memory by declaring it with the section attribute:

int __attribute__((section("CCM_DATA"))) g_Test = 5;

If this still doesn’t work, please let us know and we will help.

[support]

Sorry, as the steps for this are the same for all C/C++ IDEs, hence there is no specific VisualGDB documentation for this point.

Indeed, adding the .c file providing the function definition to Solution Explorer should solve the problem. You can read more about C/C++ declarations vs. definitions in the following thread: https://stackoverflow.com/questions/1410563/what-is-the-difference-between-a-definition-and-a-declaration.

[Author]

Posts