Forum Replies Created
-
Posts
-
Hi,
Sorry for the confusion. Please see the comment on github regarding OpenOCDPackage.
The behavior you are describing with gdb stub is to be expected. After your program initializes, it calls gdbstub_init() that outputs the “$T05#b9” packet and waits for gdb to connect. This is needed so that you can debug the initialization code of your program. If gdb never connects, ESP8266 will wait forever.
We recommend disabling the call to gdbstub_init() in the release builds to avoid this.
Hi,
We have experienced this on one of our boards – despite not returning any error codes, the FLASH programming functions did not overwrite anything. Again, as many things on ESP8266, it’s hard to say where the problem is as the FLASH programming code in ESP8266 is not open-source.
Please try first loading your program via the bootloader mode (or erasing the FLASH completely). This may reset the state of the FLASH and make it programmable via JTAG.
Hi,
We have discontinued the Texane debugger as it was less reliable than OpenOCD. You can still download it from github and specify as “custom gdb stub”, but we no longer ship a pre-built one with VisualGDB.
Slow loads could be the case if you are using a VM with USB virtualization, but should normally not happen on physical machines. If you are not using a VM, please try enabling the timing analysis mode in the GDB Session window and then check which command takes most of the time. Perhaps you are programming a large image with OpenOCD and a smaller one with the ST tool?
Hi,
This is normal. The mismatching environment issue occurs if some of the ‘export XXX=YYY’ commands in your .bashrc files are configured to run on interactive shells only (i.e. when the user logs on via SSH without a specific command to run). This would cause strange problems (e.g. if PATH is different) where some tools can be located from a normal SSH session, but could not be launched by VisualGDB, so VisualGDB automatically diagnoses this and sets the missing environment variables.
Unless you discover some really strange problems, simply pressing OK should be sufficient.
Hi,
The pre/post-build steps are available starting from the Custom edition of VisualGDB. If you are using a lower edition, you can always upgrade here: https://sysprogs.com/splm/mykey
Hi,
This is a known issue of the old VS 2017 RC that was fixed in one of the latest builds. Please update your Visual Studio (not VisualGDB) to the latest RC build.
Hi,
Thanks for the suggestion. We will re-investigate this once we receive our NodeMCU module.
Regarding support for various flavors of ESP8266, we are a bit conservative with this one. The ESP8266 chip is still very new, often works unreliably, and largely undocumented, so supporting it on the same “out-of-the-box” level as the ARM devices would drive VisualGDB price sky high. So instead of doing that, we support basic debugging scenarios on the hardware available through major distributors (i.e. DigiKey) and open-source as many ESP8266-related components as possible to make it easy for our users to work with the boards that we don’t officially support yet.
VisualGDB allows redefining the bootloader reset sequence for ESP8266 via VisualGDB Project Properties (default sequence is taken from esptool.py and is !DTR;RTS;SLEEP;DTR;!RTS;SLEEP;!DTR;SLEEP). Once we get the NodeMCU board, we should be able to tell why this does not work, but the best advice currently would be to try tweaking the sequence to get the board to reset.
Hi,
Trying out a plain ESP12 sounds like a good idea and should indeed explain whether NodeMCU is causing any interference.
Thanks for the repro project, we have managed to reproduce and fix it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1389.msi
The problem was specific to the “program without debugging” function.
Hi,
The “bad file descriptor” message is shown by OpenOCD after VisualGDB closes the gdb session and is a normal response to the end of session, so aside from being an annoyance, this message is completely harmless and can be ignored.
Normally VisualGDB should not display this text as the session has already ended, but it looks like in some cases this check does not work properly. If you could let us know the circumstances that cause this message to appear, we should be able to fix the check and prevent the message from appearing after the session has ended.
Hi,
This looks like a bug. VisualGDB is designed to always show the timeout window and to be able to cancel the hanging gdb immediately. If you could let us know the exact steps to reproduce the hang, we should be able to fix this quickly.
Hi,
Yes, the gdb stub-based debugging should not be affected by the JTAG wiring issues, so we would recommend trying it if JTAG does not work.
Hi,
Oops, the “NullReferenceException” definitely looks like a bug we would like to fix. Would you be able to describe the exact steps that cause the problem or just send us the faulty project? You can also try building our ESP8266 package on your side: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage. As we had to guess many undocumented parameters with ESP8266, we keep the related code open-source to simplify troubleshooting of issues that cannot be reproduced on our side.
We have tried creating a new project and changing the settings, but could not reproduce the error.
The JTAG problems could be caused by interference from other on-board components. From a quick look at the NodeMCU schematics, it looks like JTAG pins are used to access an SD card, so this could be causing trouble. To make a clean experiment with JTAG, we would recommend attaching the TDI, TDO, TMS and TCK to the ESP-12 module on top of NodeMCU and then physically disconnecting those pins from any wiring on NodeMCU (e.g. cutting the lines on NodeMCU).
Hi,
Normally VisualGDB tries to replicate the RTS/DTR sequence used by the esptool.py in order to reset the board into the bootloader, so it may be a bug related to that mechanism.
We will double-check this on hardware when the NodeMCU we ordered arrives.
Hi,
VisualGDB should be already able to do that (see the “Bootloader activation sequence” field in the Debug Settings), however as we have received feedback that it does not work reliably, we still show the prompt.
Let us know if the programming works without holding the button.
Hi,
Thanks for confirming that the SWO output works. We will consider supporting it more directly in the future versions.
The “GDB Session” window gets activated with VisualGDB wants to display details on slow commands or other long actions. If we did not explicitly activate that window, it would appear that the debug session is stuck and would be confusing. We would recommend placing the Output window and the GDB Session window in different tab groups so that they can be displayed simultaneously.
Regarding the “bad file descriptor”, we are aware of this problem but were never able to reproduce it reliably. If you could provide steps that get a 100% repro, we should be able to fix it.
