[support]

Hi,

Sorry, we don’t support Zynq directly as it’s not as popular as other platforms and the tools are not very reliable. Feel free to try it and post any errors you encounter. We will try to help you resolve it, but we cannot guarantee that it will work.

[support]

Hi,

Normally VisualGDB should recognize the symlink and convert it to a corresponding directory symlink on the Windows side. If this does not happen, could you share the error message you are getting?

[support]

Hi,

No problem. You can still use the GNU Make for remote builds and MSBuild for local ones, but it will require manually moving the settings around if you want to keep them synchronized. If something does not work with this setup, let us know and we will help you fix it, but it will be somewhat less intuitive and less straight-forward than using the same build system for all configurations, sorry.

Just FYI: for MSBuild projects you can still use VisualGDB Project Properties to edit common settings like Include Directories. We specifically designed a page with the same look&feel as the regular Makefile properties that edits the underlying MSBuild properties to make it easier for users who are got used to the Make-based projects.

[support]

Hi,

Thanks, the +0x10 is indeed a bug on our side. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1458.msi

Regarding the local variables, it could be quite time-consuming to query their ranges from gdb, so we don’t currently do it. We will re-investigate this in v5.3 and will consider adding an option to do that.

[support]

Hi,

Thanks for clarifying this. This is a known issue that was not addressed as it only occurs once after the initial import. It does look like a major disturbance with git, so we will fix this in the early preview builds of VisualGDB 5.3 (available in the next 1-2 months).

[support]

Hi,

The log actually shows that VisualGDB rebuilds the entire file instead of reusing the precompiled part. Can you confirm that you see the “PSF 0 (normal preamble) does not match main file.” message even after small localized changes?

Another clue here is that your source code is located on a remote system. Network can introduce significant delays when reading many small files (due to latencies) and that can significantly impact the parse time. Could you try moving the sources on the Windows side and checking if it makes things faster?

[support]

Hi,

You can convert non-MSbuild projects to MSBuild via right-clicking in Solution Explorer, but not back.

BTW, is there any reason why you don’t want to use MSBuild for remote projects? We have thoroughly optimized it to be fast and efficient in both modes (for remote builds it actually generates a temporary Makefile and runs Make on the Linux side), so we recommend it for all new projects.

[support]

Hi,

Thanks, we can address it in v5.3. Can you confirm that the “bt” command issued manually displays the correct (new) stack?

[support]

Hi,

Looks like you are trying to debug the .hex file instead of the ELF file (has no extension by default). Please double-check your debug settings; the ELF file contains the necessary symbol information and is vital for debugging.

[support]

Hi,

Please use the VisualGDB Project Properties window to create new configurations. It will ensure that all the settings get copied properly.

The Win32/VisualGDB platforms is a side effect of the way Visual Studio manages configurations/platforms. The MSBuild-based projects use the “VisualGDB” platform name, while the rest (e.g. Make-based) use Win32. If you are only using MSBuild, you don’t need the Win32 platform and can normally delete it. If your project uses both MSBuild and non-MSBuild build systems in different configurations, you will have 2 separate copies of each configuration (one for Win32 and one for MSBuild) due to VS limitations.

[support]

Hi,

WinGDB is a product that comes from a different vendor, so please contact them for support. If you mean VisualGDB instead, please try enabling the verbose mode via Tools->Options->VisualGDB and check your build output for messages explaining why the files are retransferred.

[support]

Hi,

It could be the extern “C” issue. Please try following this tutorial for instructions on fixing it: https://visualgdb.com/tutorials/tips/externc/

[support]

Hi,

Sorry for the delayed reply. We have double-checked the compatibility between VisualGDB 5.2 and VisualKernel 2.1r2 and could not reproduce this behavior.

It also looks like the package version shown in your log [VisualGDB.VSPackage.VisualGDBPackage, VisualGDB, Version=5.1.7.0] is from v5.1, not v5.2. Perhaps the uninstallation/reinstallation did not complete correctly? Please double-check the version of the “C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe” file.

If it it 5.2, but ActivityLog still mentions 5.1, please try completely uninstalling VisualGDB and installing it back. You can also explicitly run devenv.exe /setup with all other VS instances closed to force VS to update its package cache.

[support]

Hi,

It looks like your firmware does not get properly programmed into the FLASH. The default SystemInit() function for a LPC1549 project normally looks like this:

(gdb) x/10i SystemInit
   0x1f0 <SystemInit>:  push    {r7, lr}
   0x1f2 <SystemInit+2>:        add     r7, sp, #0
   0x1f4 <SystemInit+4>:        bl      0x774 <Chip_SystemInit>
   0x1f8 <SystemInit+8>:        nop
   0x1fa <SystemInit+10>:       pop     {r7, pc}
   0x1fc <SystemCoreClockUpdate>:       push    {r7, lr}
   0x1fe <SystemCoreClockUpdate+2>:     add     r7, sp, #0
   0x200 <SystemCoreClockUpdate+4>:     bl      0x4c8 <Chip_Clock_GetSystemClockRate>
   0x204 <SystemCoreClockUpdate+8>:     mov     r2, r0
   0x206 <SystemCoreClockUpdate+10>:    ldr     r3, [pc, #8]    ; (0x210 <SystemCoreClockUpdate+20>)

Please try running the “x/10i SystemInit” command from the GDB Session window to see if the disassembly instructions there look correct (you can run arm-eabi-gdb.exe <your ELF file> and run the same command there without connecting to a target to see the function contents recorded in the ELF file).

Please note that for NXP LPC devices we recommend using Segger J-Link instead of OpenOCD as OpenOCD support is not very reliable. You can also try experimenting with the FLASH parameters in the OpenOCD script files to get FLASH programming to work.

[support]

Hi,

Thanks, indeed the internal list structure has changed in one of the last toolchain releases. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1455.msi

[Author]

Posts