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

[support]

The easiest way to do that is to copy the build command line from the Output window, replace “-c” with “-S” and “-o <object.o>” with “-o <output.S>” and run it manually from the Command Line Prompt. Then the assembly output will be saved to <output.S>.

[support]

OK, please try this version http://sysprogs.com/files/tmp/SeggerEDP.dll

It will also show the data received from JLINKARM_ReadMemEx().

[support]

Hi,

Thanks for checking this. Could you please try this diagnostic build: http://sysprogs.com/files/tmp/VisualGDB-5.2.4.880.msi

Then replace the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\SeggerEDP.dll file with this one: http://sysprogs.com/files/tmp/SeggerEDP.dll

Finally start your debug session and open the View->Other Windows->VisualGDB Diagnostics Console window. It should show what exactly the Segger memory reading API returns. Please let us know what is shown there so that we could fix this.

[support]

Looks like you are still trying to use your Makefile with i586-poky-linux-gcc.exe.

In order to isolate the problem please try using the minimal Makefile we provided (with the normal GCC from the MinGW toolchain and make.exe from MinGW as well). If it works, please try explicitly using the make.exe from the MinGW toolchain instead of make.exe from the i586-poky-linux toolchain.

[support]

Hi,

Please update your J-Link EDP to v3.2 via Tools->Embedded Tools Manager. This should fix the problem.

[Author]

Posts