[support]

Hi,

Normally specifying the path in LD_LIBRARY_PATH in VisualGDB Project Properties should solve the problem. If this does not work, please try setting it manually:

1. Connect to your Raspberry Pi via SmarTTY
2. Run ‘export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/pi/project/lib/arm’
3. Try running your executable
4. If it does not work, run ‘ldd <executable name>’ and check for messages about missing libraries

Most likely you are missing some other dependencies (libraries required by other libraries) or have some invalid symlinks somewhere.

[support]

Hi,

You can simply replace your cross-compiler (or install it into a different directory and choose it from the wizard) and VisualGDB will show it as an option in the wizard. You can also retarget your existing projects to a different compiler via VisualGDB Project Properties -> Toolchain Settings.

Note that you can also download our pre-built Jessie image for Raspberry Pi that includes a newer GCC: http://gnutoolchains.com/raspberry/jessie/

[support]

Hi,

VisualGDB does that when you open a .h file or another file that is not directly included in your project. It then tries to find a source file that includes the .h file as it will give more precise IntelliSense results.

Normally it should try the previously open source file first and should be fairly fast. However, if you are using an older PC, it could slow things down. You can also disable the entire Clang IntelliSense via Tools->Options->VisualGDB->General->Tweaking->Enable Clang IntelliSense by default.

[support]

Hi,

Can you reproduce this on a basic “Hello, World” project as well? Perhaps your oscillator frequency is different from the one ESP8266 expects and you need to change it in the code?

Please also try changing the FLASH type from qio to dio and other types in VisualGDB Project Properties.

[support]

Hi,

Thanks for your feedback. The VS colors do sometimes get confused and restarting VS usually helps. Could you please explain the “changing a file then waiting while clang rescanned all my files” thing? We have designed the Clang engine to build the database in the background and only once (or when significant amount of files have been changed). If this is broken, we would certainly like to know so that we could fix it.

Please also let us know which Clang options you found confusing so that we could document them better.

[support]

Hi,

You can easily modify add support for a second SRAM as follows:

1. Open VisualGDB Project Properties
2. Go to the Makefile Settings page
3. Locate the “Linker script” field and click “Copy to project directory”
4. Edit the linker script
   1. Add another memory definition
   2. Add rules for placing contents of your SRAM2 sections into the new memory

 

Let us know if you need more details.

[support]

Hi,

The “thread aborted” error does not mean any problems, it simply means that you closed the source file while VisualGDB was still parsing it. Is any functionality broken for you, or are you just concerned with the error messages?

[support]

Hi,

You can try adding the following commands to the GDB startup commands (after target selection) in VisualGDB Project Properties:

file <first.elf>
load
file <second.elf>
load

This will load both images before debugging, however if the images share some of the FLASH pages or if the FLASH driver you are using does a full erase before programming, this won’t work. Then you would need to make a special linker script to join both ELF files into one.

[support]

The answer depends on your setup. If you have the full JTAG connection, you can combine both images into one by editing the linker script and then just debug them as one project.

The easiest way to do this is to convert the entire bootloader binary into a .o file containing a specially-named section and then modify the linker script to place that section at a given address. Let us know if you need more details.

[support]

No problem. You can also use the live variables to somewhat monitor what’s happening with our program without stopping it. E.g. define a set of global counters and watch them while your program is running.

[support]

Sure. Most likely it’s the size of debug symbols then.

[support]

Hi,

You can build an ISO file from a folder by following this tutorial.

[support]

Hi,

This is an unfortunate limitation of the semihosting mechanism. Handling a semihosting call involves stopping the CPU and reading the registers/memory. Due to the USB latencies, this takes tens of milliseconds, so your app will certainly miss some real-time events. The only reasonable workaround we could suggest is to use another UART port to print the diagnostic messages.

That said, it looks like we should be able to create a non-stop semihosting alternative similar to our live variables feature. We will investigate into this and perhaps add it to VisualGDB 5.2 feature list.

[support]

Hi,

We would recommend creating a basic LEDBlink project and testing whether it still runs without debugger. If not, something is wrong with your FLASH programming setup. If yes, try gradually adding features from your current program to the LEDBlink project to see which one breaks the flow.

[support]

Hi,

It’s hard to say why your executable is larger, it could be caused by some code being inlined/expanded, larger symbol tables, or some extra libraries. You can use the objdump tool to figure it out in detail, but if you are targeting Raspberry Pi with 512MB of RAM, 50 KB difference (0.01% of RAM) won’t have any noticeable effect at all.

[Author]

Posts