mpremote: unable to execute fs commands - mpremote.transport.TransportError: could not enter raw repl

[maxp]

Port, board and/or hardware

esp32 wroom

MicroPython version

MicroPython v1.23.0 on 2024-06-02; Generic ESP32 module with ESP32 mpremote 1.24.0

Reproduction

mpremote fs ls failed with mpremote.transport.TransportError: could not enter raw repl

Expected behaviour

expected

mpremote fs ls
ls :
           0 mrequests/

Observed behaviour

b'MicroPython v1.23.0 on 2024-06-02; Generic ESP32 module with ESP32\r\nType "help()" for more information.\r\n>>> '
Traceback (most recent call last):
  File "/opt/homebrew/bin/mpremote", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/mpremote/main.py", line 538, in main
    handler_func(state, args)
  File "/opt/homebrew/lib/python3.11/site-packages/mpremote/commands.py", line 294, in do_filesystem
    state.ensure_raw_repl()
  File "/opt/homebrew/lib/python3.11/site-packages/mpremote/main.py", line 480, in ensure_raw_repl
    self.transport.enter_raw_repl(soft_reset=soft_reset)
  File "/opt/homebrew/lib/python3.11/site-packages/mpremote/transport_serial.py", line 139, in enter_raw_repl
    raise TransportError("could not enter raw repl")
mpremote.transport.TransportError: could not enter raw repl

Additional Information

My temporary workaround is additional time.sleep(1) at line https://github.com/micropython/micropython/blob/0e490b7c8f32bb72c516985abe67147b9385dc34/tools/mpremote/mpremote/transport_serial.py#L125 before flush input.

Code of Conduct

Yes, I agree

[dpgeorge]

To debug this requires more information, because mpremote certainly works with ESP32.

Can you try MicroPython 1.24.0? Can you give the contents of your boot.py and main.py files. They may be printing things out and confusing mpremote.

[maxp]

Yes. There is a loop in main.py that reads Uart2 (modbus rtu) and prints some debug info. Probably that is the case why Ctrl-C does not work correctly.

Now I can not figure out how can I update software automatically when it prints something in stdout in main loop.

[andrewleech]

If you convert your app to use asyncio and also install and enable aiorepl then mpremote can communicate with your device without interrupting your app, it all works simultaneously.

[maxp]

Convert UART.read() to async? https://docs.micropython.org/en/latest/library/machine.UART.html

[andrewleech]

For that you would wrap it in async.StrramReader

[mzilinski]

This solution works, but there may be a more efficient or elegant approach.

def enter_raw_repl(self, soft_reset=True, timeout_overall=10): self.serial.write(b"\r\x03") # ctrl-C: 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()

    time.sleep(2) # <------------------ ADD THIS COMMAND

    self.serial.write(b"\r\x01")  # ctrl-A: enter raw REPL

[dmoimas]

I have the same issue (solvable with 1 second delay after sending CTRL+C and before flushing) if I run it under a VirtualBox VM with Ubuntu 24.04 while on Windows host it works fine without the additional delay. Using STM32H743ZI both on Nucleo and custom board.

Edit: "virgin board", boot and main.py not modified. Using UART3 for REPL on Nucleo (connected to STLINKv3 VCP)

[GregSym]

I've noted a similar error on mpy version "v1.24.1 on 2024-11-29" for "Generic ESP32 module with ESP32" - I found the time delay wasn't doing much but for some reason re-running the ctrl-A command (duplicated that line) has been working reliably for a recent development session. In theory these two techniques are both trying to solve the same problem (CTRL-A is not registered and raw repl never entered) by doing the same thing (ensuring the esp32 board registers the instruction over the serial interface)