[support]

Hi,

Thanks for the kind words and we are sorry that the debugging is not working yet.

Installing other plugins should not affect this, as it looks like some sort of a compilation flag/tool problem.

Please try creating a project with a VisualGDB toolchain and using the default VisualGDB settings. This should get a working starting point. Then you can simply compare the build logs and the produced binaries side-by-side to simplify figuring out what is causing this. Feel free to share the details of your progress so that we could give further advice.

[support]

Hi,

This is a known bug of GDB. Please try enabling the “Use X command to read memory” option in the VisualGDB Project Properties (GDB Settings page).

[support]

Hi,

Kinetis KSDK 2.0 uses a different approach for structuring files than the previous versions, please try creating a project manually by following the legacy device tutorial: http://visualgdb.com/tutorials/arm/legacy/

​​You would normally need to import at least the following files:

• The startup file (.S)
• The linker script (.ld)
• ​The drivers files (e.g. fsl_gpio.c)

If this does note help, please let us know the details on the errors you encounter so that we could help you further.

[support]

Hi,

Thanks, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.904.msi

[support]

Hi,

Are you using one of our toolchains, or your own one? Sometimes the default debug format produced by a certain version of gcc is unreadable by certain versions of gdb. We test for that in our toolchains, but if you are using your own one, this might be the case.

After changing the debug format (it should be -gdwarf-<version> as described here) do you see the list of source files when running gdb on your .o files manually?

[support]

Hi,

Those files contain precompiled headers for code completion. When you open a source file for editing VisualGDB will parse the headers it includes only once, store the result in a .npa file and then reuse it each time you need code completion results.

The .npa files are created for sources that have been modified in the last 24 hours as they are assumed to be actively edited. If you have recently imported the entire project, VisualGDB could have created those for all source files. Then you can simply delete them 24 hours after import and they won’t be re-created.

[support]

Hi,

No problem. Please try running the “info sources” command in the GDB Session window. It should show the list of source files known to the debugger. Are your files listed there? If not, please try opening any .o file with ARM gdb (arm-eabi-gdb.exe <file.o>) and run “info sources” on it. If the sources are not listed either, please double-check that you actually have the “-ggdb” flag and that the files are not stripped. If the .o files have symbols, but the final .elf file does not, please check that the ELF file is not stripped after being linked.

[support]

Hi,

It looks like the J-Link software might be getting invalid readings from the chip. Have you checked with Segger whether this chip is officially supported? Perhaps you are missing some configuration option of the J-Link GDB stub?
You can also try using OpenOCD instead. We can share our experimental script files for LPC4330 if this helps.

[support]

Hi,

Yes, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.896.msi

[support]

Hi,

osWait() should normally be defined in cmsis_os.c. Please check that the file is included in your project and then see if the function is present in the file and is not surrounded by an inactive #ifdef block.

[support]

Hi,
OK, this means that the incorrect values are coming from the J-Link software. Please try installing the latest version of it, installing the latest firmware to your J-Link and reducing the JTAG frequency.
If this does not help, please try contacting Segger support with the log showing what JLINKARM_ReadMemEx() returns, perhaps they have a better idea why it is returning incorrect data.

[support]

Sorry, looks like a bug in the debug build. Please try this one: http://sysprogs.com/files/tmp/SeggerEDP.dll

[support]

Hi,

Yes, you can edit the Makefile as follows:

#VisualGDB: FileSpecificTemplates        #<--- VisualGDB will use the following lines to define rules for source files in subdirectories
$(BINARYDIR)/%.o : %.cpp $(all_make_files) |$(BINARYDIR)
    $(CXX) $(CXXFLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep)
    $(CXX) $(CXXFLAGS) -S $< -o $(@:.o=.S)

Then modify the SOURCEFILES line so that VisualGDB regenerates the file-specific templates. This should start generating a .S file for each source file.

[support]

Hi,

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.895.msi

When you open a project with missing include paths, it will show a bar like this:

By default it will try to locate the headers in the subdirectories of the project directory and source file directories, but you can also specify search directories manually.

Once the directories are located, VisualGDB will offer automatically adding them to Project Properties:

If this does not work, please let us know. It’s a very early preview build and it may have strange bugs, however we absolutely welcome feedback on them.

[support]

Sorry, does the latest build cause this when adding the same variable as before, or are you trying something completely different?

[Author]

Posts