Forum Replies Created
-
Posts
-
Hi,
Cool. Thanks for the link. It currently looks like just a development build rather than an official release, so we are a bit hesitant to replace the previous RTOS libraries in the toolchain as it may introduce more bugs, especially given that it’s very easy to replace those manually after the installation. Once there is an official release from Espressif, we will gladly include it in our toolchain.
Hi,
Yes, this makes sense. Normally if you are using a newer gdb version, the -thread-select should be automatically replaced with the –thread argument passed to -stack-list-frames, so you’ll get 3 commands. If you disable the “show arguments” and other similar settings in the call stack window, you’ll get only 2 commands that is pretty much the absolute minimum.
Hi,
The toolchain is quite large, but it should normally download/install within minutes. Please try downloading it manually from http://gnutoolchains.com/.
OK, VisualGDB now fully supports the OTA mechanism. It will automatically generate the OTA binaries, program them, configure the bootloader and can even serve the binaries over HTTP to the ESP8266 device. Read this tutorial for more details: http://visualgdb.com/tutorials/esp8266/ota/
Hi,
Then you should be able to configure VisualGDB similarly to the Edison tutorial. Let us know if you encounter any problems.
Hi,
Yes, as long as you have a cross-toolchain for your distro. E.g. see the Intel Edison tutorial: http://visualgdb.com/tutorials/linux/edison/
You can also compile your code directly on the device or order a cross-toolchain from us if you don’t have one.
Hi,
Thanks for letting us know. We actually used the latest SDK from Espressif. Could you post a link to the update you have used so that we could include it in our toolchain as well?
As we mentioned before, there is not a lot of difference from turning on the compression. You can close the Threads and Call Stack windows in Visual Studio, then it will query less things and the overall performance should increase.
You can also try using a cross-toolchain with gdb running on the Windows side. This may improve the performance a bit more.
Hi,
The wizard layout depends on whether you are using a cross-compiler and where do you store the source files. Please provide us more details on the previous choices in the wizard so that we could check why it is disabled.
As an alternative solution you can import the project from folderA, select “Do not import files to Solution Explorer” and then add the root folder manually via Add->Import Folder Recursively. This way the main source directory from the VisualGDB’s point of view will be folderA, but the Solution Explorer contents will look like you have imported the parent folder. Let us know if that works.
Hi,
We are not aware of this problem. Where did you get that linker script? The ones shipped with VisualGDB should not contain any ‘mdata’ sections. Perhaps there is a newer version of the script available?
Good to know it works. Note that you can simply put the library directories in the ‘library directories’ field and library names without ‘lib’ and ‘.a’ or ‘.so’ to the “library names” if you want to simplify your setup.
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
