Feature suggestion: no need to hold flash on NodeMCU ESP8266 to program

[gojimmypi]

Greetings,

In order to use the GDB debugger to flash the ESP8266 via the UART, I need to hold down the “flash” button (GPIO-0) on the NodeMCU when using VisualGDB. This can be avoided.

This command for instance, will program the NodeMCU without holding the flash button:

python esptool.py --baud 115200 --port "COM1" write_flash --flash_size=8m 0 myfile.bin

This is the same esptool.py found in C:\SysGCC\esp8266\esp8266-bsp (Jan 21, 2017; 26,181 bytes)

The NodeMCU can control the Reset/Flash lines with the DTR/RTS lines on the serial port.

See: https://twitter.com/gojimmypi/status/833304790335565824

Perhaps this capability could be added to the VisualGDB ESP8266 uploader in Visual Studio?

Thanks

 

[support]

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.

[gojimmypi]

Hi.

 

Sorry I did not make that more clear. Using the command-line esptool.py – I am able to program the NodeMCU without having to hold down the Flash button. However when using VisualGDB, I always need to hold down the flash button. And not just “hold down during power cycle”… but I usually need to even hold it down until VisualGDB starts transferring code.

Thus my “feature suggestion” is to make the VisualGDB app work more like the esptool.py in not having to hold down the flash button to program it.

As this ablity may vary between different “flavors” of ESP8266… perhaps a related feature suggestion is to have a dropdown with pre-selected parameters for some well-known ESP8288 hardware, plus a “Generic” option for everything else?

[support]

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.

[Author]

Posts