esp32, ampy, rshell, pyboard & raw REPL [solved]

[devnull]

Been using 'ampy' & 'rshell' successfully on esp8266 boards without a glitch except for the 8285 and weemos MiniLite where I had to add an additional delay to wait for the startup stuff to clear, but can't solve a similar problem with the ESP32 build.

The difference between this and the other issues was that with the esp32 it just hangs, with the previous issue I would get the well known 'cannot enter raw repl' error.

I might be successful once in 20 attempts, each attempt I can either do a hard reset or completely disconnect & reconnect the uart / serial port, but it makes no difference.

I 'suspect' that it is related to all of the startup data that is emitted by thye ESP32 when it starts, but having spent seveal hours trying to nail down the cause I have made little progress.

I do not have a main.py file or use a main.py file with a single 'pass' just to eliminate the error message about not being able to find the main.py file

Code: Select all

pass

boot.py only has 2 lines to disable esp debugging (although there is still a lot):

Code: Select all

import esp
esp.osdebug(None)

There is still a lot of debug data:

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4484
load:0x40078000,len:0
load:0x40078000,len:11816
entry 0x4007a9fc
I (214) cpu_start: Pro cpu up.
I (214) cpu_start: Single core mode
I (215) heap_init: Initializing. RAM available for dynamic allocation:
I (218) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (224) heap_init: At 3FFC5098 len 0001AF68 (107 KiB): DRAM
I (230) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (237) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (243) heap_init: At 4008DD1C len 000122E4 (72 KiB): IRAM
I (249) cpu_start: Pro cpu start user code
I (43) cpu_start: Starting scheduler on PRO CPU.
MicroPython v1.9.3-615-g74ab341d-dirty on 2018-05-05; ESP32 module with ESP32
Type "help()" for more information.
>>> 

I have added some debug lines to pyboard.py:

Code: Select all

    def enter_raw_repl(self):
        self.serial.write(b'\r\x03\x03') # ctrl-C twice: interrupt any running program

        # flush input (without relying on serial.flushInput())
        n = self.serial.inWaiting()
        while n > 0:
            self.serial.read(n)
            n = self.serial.inWaiting()
        print(1)
        time.sleep(0.6)  ## HACK FOR 8285 / WEE-MOS MINI LITE #
        
        self.serial.write(b'\r\x01') # ctrl-A: enter raw REPL
        data = self.read_until(1, b'raw REPL; CTRL-B to exit\r\n>')
        if not data.endswith(b'raw REPL; CTRL-B to exit\r\n>'):
            print(data)
            raise PyboardError('could not enter raw repl')
        print(2)
        self.serial.write(b'\x04') # ctrl-D: soft reset
        data = self.read_until(1, b'soft reboot\r\n')
        if not data.endswith(b'soft reboot\r\n'):
            print(data)
            raise PyboardError('could not enter raw repl')
        # By splitting this into 2 reads, it allows boot.py to print stuff,
        # which will show up after the soft reboot and before the raw REPL.
        # Modification from original pyboard.py below:
        #   Add a small delay and send Ctrl-C twice after soft reboot to ensure
        #   any main program loop in main.py is interrupted.
        time.sleep(0.5)
        self.serial.write(b'\x03\x03')
        # End modification above.
        data = self.read_until(1, b'raw REPL; CTRL-B to exit\r\n')
        if not data.endswith(b'raw REPL; CTRL-B to exit\r\n'):
            print(data)
            raise PyboardError('could not enter raw repl')

When I execute ampy which calls pyboard.py, it never gets to print(2).

If I add code to dump all of the serial output after sending ctrl-a:

Code: Select all

self.serial.write(b'\r\x01') # ctrl-A: enter raw REPL
time.sleep(0.5)
print(self.serial.read(self.serial.inWaiting()))

The result is null:

Code: Select all

b''

So this points to why it just hangs, pyboard is waiting for the last line of the raw repl prompt and it never arrives !

Also, if I enter the repl when the pyboard attempt failed using my console (osx), it is impossible to escape the raw repl mode using CTRL-B, the only way is a hard reset.

There is absolutely no problem entering the repl from the console, this never fails.

Not really sure what else I can do to debug this, is everyone else successfully using pyboard - related utils on the ESP32 build successfully and this problem is only happening to me ??

[devnull]

To eliminate the possibility of this being related to osx, I have just tested and are able to replicate the same issue on arch linux.

[dhylands]

I've been using rshell (under ubuntu 18.04) on an ESP-WROVER-KIT (ESP32) running the Loboris port of MicroPython.

I use the following command line:

Code: Select all

rshell -a --buffer-size=30 --port=/dev/ttyUSB2

[OutoftheBOTS_]

I use ampy to write files to ESP32 Loboris port on windows PC but use putty for repl terminal

[devnull]

Thanks;

This is the micropython 'official' port of ESP32 and not the loboris port.

Unfortunately, although the lobo port has lots of functions at the moment it is just too unstable to use for anything else except 'playing' with the ESP32.

Specifically, when using the uart I get frequent 'CPU halted" and "Guru Mediation Errors" and when the device is expected to be running 24x7 for several years, just one "cpu halted" is a show stopper for me.

The 'official port' seems much more stable and I have not seen these errors for several months now.

[devnull]

OK, I have found the cause but not sure if the actual cause is the board or a bad batch of wrooms ?

I am using this: https://www.analoglamb.com/product/esp3 ... p32-board/

The enable pin pullup value on this board appears to be 12k which could be a 20% 10K resistor, or a 12k resistor

The previous problems can be eliminated by pulling the enable pin high with a jumper to 3V3, I have tried using a 2K2, 4K7 in parallel instead (3k3, 1k8) but that does not appear to solve it.

As soon as it is pulled high, connection using rshell and ampy is no longer a problem.

I hope this can save someone else some time !

[OutoftheBOTS_]

There is also a known problem of the EN pin needs a 100nf cap to ensure stability of the EN pin. See the Peripheral Schematics from the Wroom datasheet

wroom.JPG (114.82 KiB) Viewed 6594 times

[devnull]

Thanks;

Yes, adding a decoupling 100nf cap to the Enable pin also solved this.

There is a capacitor on the enable line, but that is connected to the CP2102, I can't see any others but have not checked in more detail.

I am unable to find a schematic for it.

EDIT

Just checked on google and there are several different versions of this board, I bought mine several months ago from what I believe was the original developer, and I suspect that later versions may have fixed this.

Anyway, the fix is easy to apply, just solder a smt 100nf capacitor across the pushbutton switch and the problem has gone.

[OutoftheBOTS_]

If you also don't have the 10uf and 1 uf on the 3.3v line close as possible to the wroom module then you can also have brown out stability problems as well.