[support]

Hi,

We would recommend checking device compatibility with Segger support. Their software is usually pretty reliable, so it might be a good investment to get a J-Link.

[support]

Hi,

You can try the following:

• Create a new VisualGDB project
• Copy and rename the <Project>-<Configuration>.vgdbsettings file to the new project
• Select the .vgdbsettings file as the primary output of your project via Visual Studio project properties
• Open VisualGDB Project Properties for the new project and adjust your settings

As long as the .vgdbsettings file is set as the primary project output, once you press F5, VisualGDB will automatically engage and use the settings from the .vgdbsettings file to start debugging.

 

[support]

Hi,

If the flashing is broken when you use the GDB from your toolchain, but works with our GDB, this looks like a bug in your GDB executable. You can simply replace it with the gdb from SysGCC.

You can also add the OpenOCD flashing command to the startup commands in the VisualGDB Project Properties window. This should invoke the programming automatically.

The error message is shown because you have used all the hardware breakpoints on your device. You can work around this using one of the following methods:

• Place some of the code or the entire program into RAM so that the software breakpoints will work
• Do not use more than 4 breakpoints at the same time
• Use Segger J-Link with Segger software that supports unlimited software breakpoints in FLASH (please confirm the specific versions and device compatibility with Segger)

[support]

Hi,

This is very strange. Please try using the OpenOCD’s FLASH programming commands instead of the GDB ones.

You can issue them from the GDB Session window by prefixing them with “mon”, e.g. “mon program c:/project.elf verify”. If it does not work with the ELF files, would it work with the BIN files?

[support]

Hi,

You can do it in 2 different ways:

• Select “Specify the toolchain manually” in the project wizard. VisualGDB will try to guess the right parameters for your toolchain and setup a Makefile for you.
• Use the Custom project wizard to just specify the build command line. VisualGDB will run it “as is” and won’t ask for anything else.

[support]

Hi,

Yes, the addresses look normal. The .bss section contains uninitialized variables, so it does not have the LOAD attribute by design.

Then the problem is either in the faulty hardware or in your OpenOCD settings. Please try creating a new project for the same chip using default settings and programming it. Does this work?

If yes, please replace the ELF file of the project that is broken with the ELF file from the project that works. Then run the project without rebuilding it (Debug->Start debugging with GDB). Does VisualGDB load the other project file using the current project settings correctly? Does compare-sections succeed? If no, what is different between the 2 projects’ settings. If yes, what is different between the 2 ELF files (you can enable the .map file generation to dump a general overview of the ELF file structure during building)?

[support]

Hi,

Based on a quick look, you are using a custom linker script, so the problem might be inside it.

Please use the GDB Session window to run the following commands:

• compare-sections
• maint info sections

The first command will compare each section of the ELF file (e.g. code, data, interrupt handlers) to the memory contents on the device and will pinpoint the mismatching ones.

The second command will list all sections in the ELF file. Please check that each section marked with the LOAD attribute is within your device FLASH or RAM bounds, e.g.:

 [1]     0x0400->0x092c at 0x00008400: .text ALLOC LOAD READONLY CODE HAS_CONTENTS

Section size = 0x92c – 0x400 = 0x52C, range = 0x8400 – 0x892C => within FLASH range (0x0000 – 0xFFFF). The RAM and FLASH addresses and sizes can be found in your device datasheet.

If this does not help solve the problem, please let us know the exact device you are using and attach the output of both commands.

Note that sections like .debug_info do not have the LOAD attribute and hence do not need to be checked as they are not loaded into the device.

[support]

Hi,

In order to support the .textqspi section, you will need to edit the linker script:

1. Go to the Makefile Settings of VisualGDB Project Properties, find the “linker script” field, click “create a local copy”.
2. Find the MEMORY section and add the QSPI entry there specifying the address and size of the QSPI memory on your device
3. Find the statement that places the .text section into FLASH. Copy it replacing .text with .textqspi and FLASH with QSPI. This will place the img6 variable into the QSPI memory.

Note that this will make your code expect the variable to be placed into the QSPI FLASH, but won’t instruct OpenOCD to program the QSPI memory. You will need to program the QSPI memory separately using the STLink tool (you can extract the contents of the .textqspi section from the ELF file into a separately programmable binary file by running the following command:

arm-elf-objcopy -O binary --only-section=.textqspi project.elf qspi.bin

 

[support]

If you can otherwise connect to the board (e.g. with SmarTTY), the USB cable should be OK. Most likely the problem is caused by insufficient permission on the /tmp folder.

Can you upload files there using SmarTTY? If yes, could you share a screenshot of the error displayed by VisualGDB?

[support]

Hi,

Please use the Debug->Windows->Remote Program Console command. Note that unless a remote debugging is active, this command will not appear.

[support]

Hi,

Sure, please share the gdb log showing the commands VisualGDB is issuing and the GDB responses so that we could help you figure out why programming is broken.

[support]

Hi,

The settings should normally be merged. Can you attach an archive of a sample project where the settings are not propagated properly?

[support]

Hi,

If the file is on Windows machine in a directory specified as the source directory via VisualGDB Project Properties, VisualGDB will transfer it automatically.

If not, please double-check the name and location of the file and your current file transfer settings.

[support]

Hi,

Sorry for the confusion. Did I understand you correctly that:

• Building of your project produces a valid executable, but shows the “The system cannot find the path specified” error
• Manually deploying and running the project works
• Debugging your project works
• Testing toolchain fails at the “importing specs” stage and IntelliSense does not get configured properly

If yes, please try adding “-d” to the GNU Make arguments on the Build Settings page of VisualGDB Project Properties. This should force GNU Make to print detailed log on every action it is doing, hopefully revealing what is causing the error message.

If the debugging actually does not start, please enable verbose mode in Tools->Options->VisualGDB->General->Tweaking, start debugging and check for detailed error messages. You can also check the VisualGDB Launcher Output in the Output pane in Visual Studio. Do any of those places contain any extra information about the problem?

 

[support]

Hi,

The VisualGDB variables are only resolved directly in command lines. Variables that are saved in Makefiles will not be resolved unless you specify them explicitly in Make command line (e.g. make SourceDir=$(SourceDir)). That said, you don’t need to use the $(SourceDir) in your settings. Simply specify the relative paths (e.g. subdir/LinkerScript.lds).

[Author]

Posts