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

[support]

Strange. Could you please archive the project and send it to us via our support form? If we can reproduce it on our side, we’ll fix it very quickly.

[support]

Hi,

OK, please try the following Makefile from the command line:

test:
    gcc -DTIMESTAMP=$(shell C:/mingw/msys/1.0/bin/date.exe +%s) -E test.c -o test.E

You can use it with the following test.c file:

int timestamp = TIMESTAMP;

If this does not work, please let us know the error you get with this simple file. If it does, please compare the syntax here with your Makefile.

[support]

Hi,

VisualGDB does not normally *overwrite* the Makefile, it simply edits the SOURCEFILES line and a few other relevant lines, but only if it finds special tags in the file. Please let us know more details on what exactly is broken and we could suggest how to fix it.

[support]

Hi,

We would recommend exporting it as GccARM, unpacking the archive to any location within your source control system and then simply using the “Import Folder Recursively” command to import those files into your project.

If you run into problems with missing include files, you can try a daily build of VisualGDB 5.2 that has experimental support for repairing them automatically. Let us know if you want to try it out and we’ll post a link to it.

[support]

Hi,

This happens because the FreeRTOS port hardcodes the ISR vector table name variable name as ‘__isr_vector’ and the VisualGDB startup file uses a different name.

The easiest way to solve this is to replace this (in port.c):

    "   ldr r0, =__isr_vector     \n" /* Locate the stack using __isr_vector table. */
    "   ldr r0, [r0]              \n"

with that:

"   ldr r0, =_estack     \n"

Note that the “ldr ro, [r0]” line will be removed, as _estack already contains the end-of-stack address.

Let us know if you encounter further problems.

[support]

Hi,

Thanks for pointing this out, we will fix it in the next release of the Tiva BSP.

[Author]

Posts