Forum Replies Created
-
Posts
-
Hi,
Yes, the gdb stub sometimes produces strange results. Generally the ESP8266 is much less stable than the ARM devices like CC3200, albeit much less expensive.
We would recommend trying to get JTAG to work if the gdbstub does not work. We have just released a new toolchain version that improves the JTAG debugging stability by resetting some of the registers that interfere with debugging. Please try using it and let us know if it works.
Hi,
We have just released an updated version of our ESP8266 toolchain with improved stability. Could you please try it and let us know if the problem still exists?
Hi,
Thanks for pointing that out. It does indeed look like we shipped the old one. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.683.msi
Hi,
VisualGDB is using the version 1.6.0 (June 12 2015) that should include that fix. If it does not work with your machine, most likely it is another bug of libssh2. We will consider updating to 1.7.0 in one of the next VisualGDB releases.
Hi,
The _estack and main() errors are not critical and can be ignored. They are displayed because the structure of an esp8266 image is different from many other architectures and some auxiliary features do not work with those. It should not interfere with the debugging. Does the LED actually blink? Are you able to stop at breakpoints?
Hi,
Do you see the programming progress bar while VisualGDB is programming the module? If yes, the connection is OK and the problem is with the SPI FLASH.
We have received feedback that some of the modules come with very unreliable FLASH chips that have troubles being reprogrammed. We would recommend getting a dev board from Olimex as they seem to be using better SPI FLASH chips.
This might the case if the error output format of the compiler has changed. The regexes are indeed case-sensitive. Please try moving the file out of the way, building the project to see the raw error message and then using the online regex debugger to see whether the regex in the file matches the output. If not, you should be able to easily adjust it. Let us know if you need help.
Hi,
It looks like you are trying to add header files (.hpp) to the library list. This won’t work as those are different types of files. Header files contain definitions of your functions and you should be referenced by adding their directories to the Include Directories field. Then the #include<> directories will handle them properly. When this is not setup properly, you will get errors like “cannot open file xxx.h”.
Library files (.a or .so) contain compiled implementations of your functions and should be added to the Library Names field (without the ‘lib’ prefix and extension, more details here). When some libraries are missing, you will typically get errors like “unresolved reference to xxx”.
We would recommend first solving the problems with the header files (the code should at least compile and then get stuck at ‘unresolved reference’ problems) and then add the missing libraries to VisualGDB Project Properties. You can find the libraries by simply searching the OpenCV build directory for .a and .so files.
Hi,
This is not supported directly, however can be easily achieved with per-user variables: simply set them so that other users will have an irrelevant mapping (like /tmp/suchpath <=> c:\nosuchpath) and you will get the same effect.
Hi,
Yes, you can change the “CMakeLists.txt directory” field on the CMake Settings page of VisualGDB Project Properties.
Hi,
Thanks for reporting this. The compression implementation comes from the libssh2 library that VisualGDB/SmarTTY is using and we don’t really want to modify it as it could create more problems that it would solve. You can experiment with building the latest version (we use 1.6.0) from sources and replacing the DLL that comes with VisualGDB.
If the debugging is slow, most likely this is caused by the latency and not the bandwidth (unless you are debugging over a dial-up connection or something similarly slow). We would recommend using the command timing analysis button in the GDB Session window to find out which commands take the most time.
Hi,
Just tried reproducing that, but the StdPeriph LEDBlink sample did show up. Perhaps something else caused it to disappear?
Are you using the Clang IntelliSense engine? When we tried reproducing the problem, pressing ctrl-space showed the suggestion list with one entry, but did not result in ‘stop_realtime_timeraltime_timer’.
Hi,
We would recommend first ensuring that you can add the library to a basic “Hello, World” project by following one of our OpenCV tutorials. Once that works, simply take a note of the include paths and library names added to the Hello, World project and add them manually to the Qt project via VisualGDB Project Properties. This will let your Qt project use OpenCV the same way as the Hello, World project does.
