Weemos Mini Lite works well but hard resets when entering REPL

[devnull]

I have noticed that the weemos mini-lite with onboard 8285 instead of 8266 reboots whenever you enter REPL via the serial console.

Can someone else verify this ??

Entering REPL in the same way on a ESP12 does not cause a reboot of the device.

[devnull]

Bump;

Would someone mind verifying this for me as right now it makes it impossible to use a serial REPL for debugging !

Many Thanks

[pythoncoder]

I suggest you read viewtopic.php?f=16&t=2827&hilit=wemos+mini+pro.

[devnull]

Peter, thanks, but I have read that thread several times before and just re-read it again and I don't see anything that refers to the device rebooting when entering REPL Mode.

Maybe I did not make it clear before, the device flashes fine, I can load and run any and all of my code that runs on the ESP8266.

The only problem, I am facing is that when it is running normally, as soon as you login to REPL via serial console to monitor what is happening, the device resets itself.

So if for example it is running code in an endless loop and doing exactly what it should be doing, by entering REPL, it will break out of that loop by doing a hard reset, and you get all of the same info / debug data as you get when restarting an ESP8266.

There's no problem whatsoever in flashing or running code, this is only an issue when opening a serial connection which appears to cause a hard reset.

[Roberthh]

That could be a problem of DTR etc flow control. Have you set your terminal emulator for flow control = None?

[devnull]

Hi Robert;

I am using OSX built-in screen command, same as I use for ESP-12 and ESP32, the setup and code being executed is 100% identical.

If I connect a ESP-12 to the terminal, start a loop, logout and in again, the loop continues to run, if I then detach, disconnect and connect the weemos, and do the same thing: start a loop, log out, log in again and the loop has been terminated and the device reset.

So if you have code running on your device, in a loop and you login to the weemos via serial REPL, your code continues to run and there's no system restart ?

[Roberthh]

The way, the CP2104 is connected to the ESP8266 on a Wemos device (and Huzzah feather, esp32 thing ...) is, that they use RTS and DTR to control RST and GIO0 of the ESP8266. That allows resetting the device and setting it into firmware download mode via the modem control lines. If just GND, RX and TX weer connected, you would not have that option.
So when RTS is low and DTR is high, the ESP8266 is reset. RTS and DTR are controlled by the PC and the PC terminal software via the driver. And I tghinks that's what happening here. So that's what you have to look at. I did not set up a test yet, I have to know what precisely you are doing.
When you say "logout and login again", does that really mean: log our as a user, or just lock screen? Does the screen command stay open, oder do you terminate it and restart it, maybe even implicitly by telling OS X to re-open all apps that had been open at logout time?

Update 1: I just tried with OS X 10.11, screen or picocom and a Wemos D1 Mini hooked up to an oscilloscope. With both apps a reset signal of 200us duration is created when they start. That may be caused by opening the serial communication to usb. The screen option -fn does not make a difference. Interestingly, the Wemos D1 is not affected by that pulse. But other devices may reset then, especially if they use different USB/serial bridges.

Update 2: I could not see a reset signal when starting screen with a Huzzah feather ESP8266, which has a SIL2104 (CP2104) chip like the Wemos d1 mini Pro.

[devnull]

Now I understand what you mean, and yes this is the cause, all the while I thought that it was some firmware anomaly with the 8285 device.

I just connected my scope and the reset line is indeed pulled low for a full 4 seconds (not 200us) and GPIO0 pulled low for 100ms whenever you enter REPL via serial console resulting of course in a hard reset.

in the schematic: https://www.wemos.cc/sites/default/file ... ni_pro.pdf U2 in the bottom left hand corner GPIO0 and RESET are triggered by RTS and DTR as you said.

Now, how to disable this feature whilst still permitting the ability to flash the device ?!

Like you I have tried the -f and -fn modes, that makes no difference:

Code: Select all

-f, -fn, and -fa
            turns flow-control on, off, or "automatic switching mode".  This can also be defined through the
            "defflow" .screenrc command.
            
wee="/dev/tty.wchusbserialfd1340"
screen -fn $wee 115200
screen -f $wee 115200        

[Roberthh]

I'm surprised that you use the CH340 driver, because for the CP2104 I used the Silicon labs driver from that page: http://www.silabs.com/products/developm ... cp-drivers.
But maybe your chip uses a CH340 chip and not the CP2104. By the way: I used the driver from that page:
http://www.wch.cn/download/CH341SER_MAC_ZIP.html

[devnull]

Robert, the schematic shows CP2104, but the actual device fitted to the board is a CH340G.

I have tried all possible combinations of flow control using CoolTerm and all result with the same thing, a hard reset.

This also explains why when you use a utility such as ampy to transfer files, it fails and it's necessary to add an additional delay into pyboard.py in order to wait for it's hard reset to finish.

I'm not sure this can be solved, and it's not really very friendly for development work !