Mos tool always resets esp32 on linux?

General
#1

Hi

  1. My goal is:

use mos tool commands in linux VM without resetting the ESP32 device every time

  1. My actions are:

mos console
mos ls

etc.

  1. The result I see is: [show the result - log, etc]

On windows it works fine. On ubuntu 18.04 LTS VM there is a spurious reset pulse issued of around 500us length. Also similar activity on the boot pin.

Tried with both CP2102 and FT2232H based USB adapters, using ESP-WROVER-KIT as well as other boards.

  1. My expectation & question is:

I would like to be able to use the mos tool on linux without resetting the ESP32 for each command.

Question: can someone confirm that this can be made to work on linux? I thought I saw it working OK in cesanta videos but it might have been OS-X or something.

Thanks
John

#2

Try the --set-control-lines=false option.
Ref. mos help --full: --set-control-lines Set RTS and DTR explicitly when in console/RPC mode (default true)

#3

Hi, thanks for the suggestion. I tried that before but will now look in more detail.

mos console -> 1.5ms low pulse on EN, resetting the device:

mos_console
mos_console.PNG1026×825 48.6 KB

mos console --set-control-lines=false -> EN goes low and stays low, holding device in reset:

mos_console2
mos_console2.PNG1026×825 49.7 KB

However this does in fact work on the standard development boards since the USB UART controls lines go through an exclusive-or circuit before they get to the ESP32 (the strangely wired pair of transistors you see on the circuits).

Unfortunately I omitted this circuit from my hardware since it seemed to not be needed :slight_smile: ! As can be seen from the first scope shot it does not help anyway for standard mos console since the reset line is held low longer than the boot line. But it does seem to help with mos console --set-control-lines=false since the two lines go low almost simultaneously. In fact the EN line goes low last, with a ~4us delay so the reset is not triggered then; the exclusive-or circuit protects the system.

So to summarize mos console --set-control-lines=false is a solution for most standard boards but not for me unfortunately. It does work on windows but not on linux.

Thanks

John

#4

My dev boards (mainly Wemos 32, 32Pro, D32, D32Pro) are working without problems on Debian 9.
Your issue might be related to the way the driver manipulates the DTR and RTS signals.

#5

OK thanks!

It looks like those include the transistor circuit too, so it must be a known issue for it to be used on all these dev boards. I will include the circuit on the next revision of the PCB, it is only a single cheap part by the look of it (a dual transistor).

Thanks
John

#6

Life saver!

I needed the --set-control-lines=false

I personally can’t understand what is different between our circuit and the devkitc, so have asked our EE to look into it. IE, our transistor setup is the same…

1 Like
#7

Greeting @nliviu,

I am using a ESP32 dev board with 30 pin out. Top show ESP32-WROOM-32, bottom shows ESP32S.

I have tried the command

mos --set-control-line=false call Sys.GetInfo

on ESP32 mos 2.20 (released 14 Dec 2021, I think) via mac osx big sur. The uptime is alway less than 2. Using Coolterm to monitor the uart and turning dtr and rts off does not help either to stop the esp32 from reseting when uart connect.

Is there a way to prevent the uart from reseting? I have read that espressif has acknowledged the bug and release a version that should fix the bug. Are we on the same page as espressif?

Regards