Stopping minicom makes the miner to stop working to (reboot)

[PsySc0rpi0n]

I have an ESP32 WROOM with no LCDs, screens, LiLos or whatever. Just the ESP32 WROOM alone, connected to a Raspberry Pi 4. I access the ESP32 via ssh connection to the RPi4 and then via serial port.

Sometimes, when I have minicom running, the internet connection goes down and I have to close the ssh connection window. When I start another ssh window to connect to the RPi 4 and then start minicom, the ESP32 WROOM seems to be rebooting.

This is what I see when I start minicom:

I presume this shouldn't happen. The firmware should be always running and not booting the ESP32 WROOM whenver a minicom session is closed for whatever reason!

Any thoughts?

[PSLLSP]

Maybe that minicom resets the ESP32 device with some UART signal line, like DTR or RTS. ESP-WROOM-32 uses external UART chip for serial communication, there are different modules with different UART chips and there could be differences how these external UART chips are wired to ESP32 chip. I am not sure, it is just my guess... The UART that is used in your ESP32-WROOM-32 module could be found with lsusb command or with dmesg | tail (connect ESP32 module to RPI and check dmesg output, it will have details about new USB device).

Try to play with minicom configuration, check what action is executed when it opens serial port...

Read how to disable DTR and experiment...

Try different serial terminal program. You can try screen or miniterm; miniterm is part of python3 pyserial package, it is just a simple python program... I use miniterm and I have not experienced chip resets on serial connection.

Other trick is that you can start screen on your RPI4 and start minicom (or any other program) from screen session. Advantage of screen sessions is that you can have several sessions over single ssh session and when you disconnect, your programs running under screen session are not terminated; you can reconnect to your RPI4 and reconnect to the previous session (screen -dx). Check screen and how to use it, it is powerful tool...

screen could be used as a serial terminal too, screen /dev/ttyUSB0 115200. Use CTRL+A k to close serial connection...

I see from your terminal, that your ESP-WROOM-32 is flashed with "wrong" firmware. Reflash it with WebFlasher. You should not see those errors about GPIO. Check issue #266 for details...

A bonus, hint how to increase your mining hashrate. You use RPI4 to connect to ESP-WROOM-32 module; ESP32 module hashes at speed about 55 kHps. Your RPI4 is powerful computer and can mine bitcoin too. First, you need a miner, cpuminer is a good option, it can run at ARM cpu but you have to compile the code. Then use screen and run cpuminer in one terminal, you can hash with just one or all (4) cores, it is on you; watch RPI temperature, consider a heatsink, maybe even a fan. Even single RPI core has much higher hashrate than ESP32, about 900 kHps, it is like 16 ESP32 miners! Is it enough to find a block? Probably not... ;-) Use of cpuminer is described in issue #234...

[PsySc0rpi0n]

Ok, this post is about one other EPS-WROOM-32 I have at home, connected to a RockPro64 sbc. I also flashed it the same way I flashed the one I have at work, which is conencted to the Raspberry Pi 4.

I'll leave here some more info about my scneario at home. This ESP I have at home is one of those bought from China and uses an CP2102 UART. I connected it to a RockPro64 sbc (single board computer I have at home) but now I removed it for convenience and attached it to my laptop.

This is what I see in dmesg:

[76138.787194] usb 2-2: new full-speed USB device number 6 using xhci_hcd
[76138.966474] usb 2-2: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[76138.966492] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[76138.966499] usb 2-2: Product: CP2102 USB to UART Bridge Controller
[76138.966504] usb 2-2: Manufacturer: Silicon Labs
[76138.966508] usb 2-2: SerialNumber: 0001
[76139.004758] usbcore: registered new interface driver usbserial_generic
[76139.004776] usbserial: USB Serial support registered for generic
[76139.008690] usbcore: registered new interface driver cp210x
[76139.008710] usbserial: USB Serial support registered for cp210x
[76139.008744] cp210x 2-2:1.0: cp210x converter detected
[76139.009586] usb 2-2: cp210x converter now attached to ttyUSB0

This is the command I use to flash the firmware binaries: esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 write_flash --verify --flash_freq 40m --flash_mode dio 0x10000 0x10000_firmware.bin 0x1000 0x1000_bootloader.bin 0x8000 0x8000_partitions.bin 0xe000 0xe000_boot_app0.bin

Why you say I have the wrong firmware flashed?

I can try the cpuminer at my home board because I have heatsink and a fan on top of the cpu!

[PSLLSP]

Why you say I have the wrong firmware flashed?

I see errors in your serial console:

[   138][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
E (132) gpio: gpio_set_level(226): GPIO output gpio_num error
[   141][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
E (140) gpio: gpio_set_level(226): GPIO output gpio_num error

The file 0x10000_firmware.bin in the git repository is not the same as 0x10000_firmware.bin used by Webflasher. You want to replace it with 0x10000_firmware_v1.6.3.bin that is in the git repository. Or flash NerdMiner with WebFlasher. I know that WebFlasher doesn't work for some ESP-WROOM-32 modules, I do not know why. It seems that some modules with UART CP210x cannot be flashed with WebFlasher; I had this issue and you confirm it; I assume you use esptool.py because WebFlasher does not work for you.... Maybe that some signal (DTR or RTS) is not connected from UART to ESP32 chip...

Check issue #266 for details...

However lsusb doesn't show it.

No output from command lsusb | grep -i "10c4:ea60" ?