mpremote fails with TransportError

[tsh-et-al]

I've recently been advised to switch from ampy to mpremote. I've just installed mpremote but it fails when I use it to access my RP2040 thus:

c:\>mpremote fs ls
b''
Traceback (most recent call last):
  File "c:\users\anon\appdata\local\programs\python\python37\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\users\anon\appdata\local\programs\python\python37\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\Scripts\mpremote.exe\__main__.py", line 7, in <module>
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\main.py", line 569, in main
    handler_func(state, args)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\commands.py", line 327, in do_filesystem
    state.ensure_raw_repl()
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\main.py", line 511, in ensure_raw_repl
    self.transport.enter_raw_repl(soft_reset=soft_reset)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\transport_serial.py", line 159, in enter_raw_repl
    raise TransportError("could not enter raw repl")
mpremote.transport.TransportError: could not enter raw repl

It seems to be able to automatically find the correct USB port, but a naked command only responds to CTRL/X or CTRL/] All other chars are ignored thus:

c:\>mpremote
Connected to MicroPython at COM14
Use Ctrl-] or Ctrl-x to exit this shell

It also gives me a weird version number thus:

c:\>mpremote --version
mpremote 0.0.0-unknown

ampy works OK:

c:\>ampy -p COM14 ls
/main.py

Any advice please?

[tsh-et-al]

Solved by installing latest Micropython.

[bulletmark]

How did you install mpremote?

[tsh-et-al]

Just like it says here:
https://docs.micropython.org/en/latest/reference/mpremote.html#mpremote-command-fs

[bulletmark]

Those instructions say two different ways. Which one did you use?

[ynyxxx]

I encountered the same issue. However, I managed to correctly identify the version of Micropython, and this issue appears to be sporadic.

[tsh-et-al]

I jumped the gun a bit.

mpremote fs ls

now works OK, as does using mpremote to copy files from laptop to pico. But copying files from pico to laptop fails:

[c:\>mpremote fs cp :test.10000 junk
cp :test.10000 junk
  File "c:\users\anon\appdata\local\programs\python\python37\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\users\anon\appdata\local\programs\python\python37\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\Scripts\mpremote.exe\__main__.py", line 7, in <module>
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\main.py", line 569, in main
    handler_func(state, args)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\commands.py", line 395, in do_filesystem
    do_filesystem_cp(state, path, cp_dest, len(paths) > 1, not args.force)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\commands.py", line 158, in do_filesystem_cp
    data = state.transport.fs_readfile(src[1:], progress_callback=show_progress_bar)
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\transport.py", line 136, in fs_readfile
    chunk = self.eval("r({})".format(chunk_size))
  File "C:\Users\anon\AppData\Roaming\Python\Python37\site-packages\mpremote\transport_serial.py", line 282, in eval
    return ast.literal_eval(ret.decode())
  File "c:\users\anon\appdata\local\programs\python\python37\lib\ast.py", line 46, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "c:\users\anon\appdata\local\programs\python\python37\lib\ast.py", line 35, in parse
    return compile(source, filename, mode, PyCF_ONLY_AST)
  File "<unknown>", line 1
    567890123456789012345678901234567\r\n0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567\r\n01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567\r\n012345678901'

                                                                                                                             ^
SyntaxError: unexpected character after line continuation character

c:\>

I think a Python upgrade on my laptop is needed. This is a problem for me because I'm running Python V3.7.2 (from 2020) on Windows 7, Python versions beyond V3.8 wont run on W7 and I dont want to upgrade Windows. :(

[peterhinch]

Run Linux in a VM?

[ynyxxx]

I encountered the same issue. However, I managed to correctly identify the version of Micropython, and this issue appears to be sporadic.

Solved. There was an infinite loop in the main program I originally wrote in.

[tsh-et-al]

I used: pip install --user mpremote

…

On 26 July 2025 22:25:56 BST, Mark Blakeney ***@***.***> wrote: CAUTION: This email originated from outside of the LMB: .***@***.*** Do not click links or open attachments unless you recognize the sender and know the content is safe. If you think this is a phishing email, please forward it to ***@***.*** -- Those instructions say two different ways. Which one did you use? -- Reply to this email directly or view it on GitHub: #17756 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

[bulletmark]

Using pipx is better but really both are legacy tools nowadays. I am not sure if uv will install on Windows 7 but you could try. Do pip uninstall mpremote then install uv and type:

uv tool install -p3.13 mpremote

That will install a standalone Python 3.13 environment (on the fly and very quickly) and then will install mpremote to use that python.

With uv you don't even need to specify a python version as uv will check the project metadata and will see the minimum supported python version then install a compatible version if needed. However, mpremote defines itself as compatible with python >=3.4 in it's pyproject.toml which is a bug. It should be >=3.8. So we need to explicitly specify a python version as above.

[Josverl]

off topic: Can you trust a known in securable system ( >5 years after extended EOL ) that is connected to the internet ? If you are not held back by incompatible hardware , personally I have taken the discomfort of the update over the pain of an almost certain infection.