Forum Replies Created
-
AuthorPosts
-
supportKeymaster
Hi,
You can use the system() function:
#include <stdlib.h> int main() { system("sudo apt-get upgrade"); return 0; }
Let us know if this works.
supportKeymasterHi,
Yes, please use the Clang IntelliSense engine. It is fully compatible with most of the Clang/GCC language extensions.
supportKeymasterHi,
Most likely, something gets broken with the build commands. Feel free to open another topic on that and we will provide troubleshooting advice.
supportKeymasterHi,
Sorry for the confusion. We did not mean custom steps, we meant changing the build subsystem from Make to Custom on the first page of VisualGDB Project Properties. This will replace the Makefile settings page with a Custom build settings page allowing more customization of the build/clean commands.
We add ‘clean’ to the default command in order to support cases when the default command passes extra variable values or command-line switches to GNU Make.
supportKeymasterHi,
Most of the ESP8266 memory is used by the library code from Espressif, so this is to be expected.
Regarding other problems:
- Resetting the device will clear the breakpoints in the RAM. To re-enable them, simply click the “Break all” button in Visual Studio and then resume debugging as usual. If this does not help, please try adding forced breakpoints (asm(“break 1,1”)) in your initialization functions and checking that they get invoked after a reset.
- What do you mean by “use UART with VisualGDB”? Connect to a COM port from VisualGDB so that you can see what your device is printing or are you taking about the UART functions of the ESP8266 SDK?
supportKeymasterHi,
The error simply means that your program’s code did not fit into the instruction RAM. Most likely enabling optimization has inlined some of the functions or unrolled some loops resulting in the size increase. You can try optimizing the code for minimal size with -Os instead of -O3. Alternatively you can use the Embedded Memory Explorer to see which exact functions contribute the most to RAM utilization.
supportKeymasterHi,
The error simply means that something in the build process failed without showing any error messages that VisualGDB could recognize. As suggested in the Errors list, please check the Output window for the details of the error.
supportKeymasterHi,
Most likely it is just a coincidence and the problem was fixed by re-downloading OpenOCD.
“Warn : unable to change server port after init” was definitely caused by our bug and we fixed it almost immediately after releasing the affected version. Most likely you have originally downloaded that version and then replaced it with a fixed one.
supportKeymasterHi,
We normally recommend using the Custom build system with custom makefiles. The purpose of the “GNU Make” system is to provide a user-friendly front-end for GNU Make for those users who don’t want to go deep into customizing Makefiles and just prefer setting things like CFLAGS via GUI and expect everything to work out-of-the-box. So we intentionally keep the settings there simpler than in the Custom build subsystem.
supportKeymasterHi,
This error means that the debug symbols for your module do not contain enough information to find the memory address of the requested variable. It can happen due to a variety of reasons:
- Incompatibility between your gcc and gdb versions
- Incompatibility between the debug information format (e.g. DWARF 4) and your gdb version
- Missing “-ggdb” in your compilation flags
- Symbols being stripped from the executable after it is built
- Symbols not matching the loaded executables
We would recommend setting up a “hello, world” project using the same build/debug machines, ensuring that it works and then comparing compiler flags and gdb versions with your actual project in order to find out what exact difference breaks the variable viewing.
supportKeymasterHi,
You can find that out by disabling multi-threaded build via VisualGDB Project Properties -> Make Settings -> Build Command -> remove the “-j<number of CPUs>” (so that all files are compiled one-by-one) and checking the last build command (will look like arm-eabi-gcc -c <file.cpp> -o <file.o> …) in the build log before the error.
Then you can replace -c with -E and <file.o> with <file.E> and run the command manually. This will run the preprocessor on the input file and save the preprocessed output to a file named <file.E>. The preprocessed output will show what exact macros got expanded and which parts of the files got compiled or skipped.
If you are still not sure, please simply send us the single-threaded build log and the .E file so that we could suggest a solution.
supportKeymasterHi,
This is a known bug that was recently fixed. Please try re-downloading the OpenOCD debug package again and if this does not help, update to VisualGDB 5.1r6.
supportKeymasterHi,
Not sure why the ‘make clean’ command starts the build. Are you using a custom Makefile?
Please try enabling the verbose mode in Tools->Options->VisualGDB->General->Output and selecting Build->Clean Solution. VisualGDB will then show what exact commands it runs.
If this does not help pinpoint the problem, please post the output of the verbose cleaning here so that we could provide further advice.
supportKeymasterHi,
That’s a known issue. VisualGDB automatically substitutes register names to support data tooltips for inline assembly. As a workaround please use the Locals window or rename your variables.
supportKeymasterThanks for the advice, we will consider that if Mono popularity continues to grow.
-
AuthorPosts