Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
The brace formatting is controlled by a Visual Studio setting under Tools->Options->Text Editor->C/C++->Formatting->Indentation->Indent Braces:
Please double-check that it’s not enabled for you. If it is disabled, but VisualGDB still formats the code incorrectly, please let us know which version of Visual Studio you are using so that we could suggest further diagnostic steps.
support
KeymasterHi,
We recently fixed the global “Enable Clang IntelliSense by default” so that it applies to the running session as well.
Perhaps we are talking about different windows. Could you attach a screenshot of the window that pops up for you? We should be able to advise you how to disable it then.
support
KeymasterOK, then we will update the parser so that the next version of our nRF51 package contains the correct definitions. Please also feel free to attach your patched XML file here so that everybody could download it before we release the next version.
support
KeymasterHi,
We don’t do that because in many cases the machine with the previous VisualGDB installation is inaccessible. But we do respond quickly if you request an activation reset via our support channels.
October 30, 2015 at 23:37 in reply to: Can't add libraries: Error stm32f0xx_i2c_cpal.h: No such file or directory #7133support
KeymasterHi,
Please add the include paths via VisualGDB Project Properties -> Makefile Settings -> Include Directories.
This will configure both IntelliSense and your compiler correctly.
support
KeymasterHi,
Normally when you change something on the Makefile Settings page and click “Apply” VisualGDB should retest the settings and update IntelliSense. Did this not happen when you changed the toolchain? Does it retest correctly when you change, let’s say, CFLAGS?
We’ll add an option to select the language directly in the wizard in the next version of VisualGDB. We will also see if we can make the Program Output to be the default output after debugging.
support
KeymasterHi,
Could you try replacing the contents of the main source file with the following:
#include <stdio.h> #include <stdlib.h> int main() { printf(">%s<\n", getenv("LD_LIBRARY_PATH")); }
Does it show the correct LD_LIBRARY_PATH when you debug it from VisualGDB?
support
KeymasterHi,
Yes, we have created the Clang-based IntelliSense because the VS IntelliSense does not work well with many GCC-specific extensions including the C++11 ones.
You can also enable the Clang IntelliSense globally via Tools->Options->VisualGDB. Please provide us an example of the code formatting problem in the other thread so that we could release a hotfix or suggest a workaround.
support
KeymasterHi,
The Clang IntelliSense includes formatting because switching the IntelliSense engine actually also disables the original formatting. Normally VisualGDB should import your VS settings and format your code accordingly. If it does not happen, we will certainly fix this. Could you give an example of a code formatted with our IntelliSense, with original IntelliSense and a screenshot of your VS indentation settings? This should allow us reproduce the problem and fix it.
support
KeymasterHi,
Please try changing the gdbserver port in VisualGDB Project Properties. Looks like the original port is already used by something else.
support
KeymasterHi,
The compiler uses a different path from linking. In fact, if you have specified relative paths to the libraries and not used the -L<directory> -l<library name>, the linker may hardcode the relative path in the executable leading to strange errors. We could help you fix this if you could share your linker command line, the exact LD_LIBRARY_PATH, the exact location of one of the libraries and the matching output from LDD.
support
KeymasterHi,
Can you confirm that the only missing registers are the second/third instances of some peripherals (e.g. TIMER1, TIMER2 are missing while TIMER0 is OK)? Looks like the Nordic SVD files are using an undocumented extension for those devices, so we should be able to update our SVD parser and fix this globally.
support
KeymasterHi,
Looks like there is some bug with stepping over instructions. We’ll follow up with Espressif on that and see if they could provide a solution.
Have you connected the nRST pin with J-Link? When we tested it with ESP8266, it did not start roughly 1 time out of 10, but worked 90% of the time. Please also try lowering the JTAG speed and experimenting with the “Reset mode” setting.
Regarding baud rates, this looks like a typo. The 115200 baud rate is the bootloader baud rate that indeed uses autobaud. Please also try changing the first one to 74880. We have updated the description and re-uploaded the toolchain. You can download the updated toolchain installer from http://gnutoolchains.com/esp8266.
support
KeymasterHi,
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:
- Connect to your Raspberry Pi via SmarTTY
- Run ‘export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/pi/project/lib/arm’
- Try running your executable
- 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
KeymasterHi,
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/
-
AuthorPosts