ESP8266 Micropython "Could not enter raw repl"

[ioncodes]

I'm using this board https://www.olimex.com/Products/IoT/MOD-WIFI-ESP8266-DEV/. When I try to run
"sudo ampy --port /dev/ttyUSB0 run test.py" or any other command, it says "Could not enter raw repl". When I enter that, micropython says "raw REPL; CTRL-B to exit".

[emilithe]

I have similar problem, but with NodeMCU DEVKIT V1.0 board (running MicroPython v1.8.7-7-gb5a1a20a3)

Did you have any code on board running while trying to execute ampy command or any terminal opened?

In my scenario, ampy (ls command) was not able to enter raw repl while code with virtual timer initialised was running on board.
After deinitialising timer (in REPL) and closing terminals ampy works as expected.

[g-sam]

In my case, the cause was code on the board reading from UART 0.

[markserrano915]

@g-sam What does it mean that it's reading from UART 0? Does it mean you just need to change something to read on a different UART? If yes, how?

In my case, the cause was code on the board reading from UART 0.

I had been trying to solve the same problem with my ESP32 for two days now (I think I got the same issue on ESP8266 01 but I probably gave up). But then out of the blue I was able to make it work today.

So when I plugin the board on my Macbook 2013, that's when I get this unable to enter REPL issue. But as soon as I plug it in on my Raspberry Pi, I am able to run the same ampy commands without issues!

My immediate solution is:

1. Do the coding in Mac (because it's more convenient to type in there).
2. Push to git
3. Pull in the code to my Raspberry Pi
4. Use Raspberry Pi's for uploading code to the board via ampy

By the way I got the same problem with rshell. I resolved the issue the same way!

Some interesting observations:

• When I use picocom on my Mac, before I am able to enter on the Micropython REPL shell, the terminal spits out some garbage text and afterwards I can work on picocom without any issues (until I use ampy or rshell)
• When I use picocom on my Raspberry, there are no pre-garbage text. I go straight to the REPL with no issues with ampy and rshell

[g-sam]

I meant I had a sensor plugged into UART 0, which the USB also uses, so there was some kind of conflict. ESP8266 only has one UART-in, so you can't change it. Not sure about the ESP32 and curious if anyone can explain your observations

[zjor]

I have the same issue on my Mac 10.12.3 with Wemos D1 mini
ampy --port /dev/cu.wchusbserial1410 put wget.py

  File "/Library/Python/2.7/site-packages/ampy/pyboard.py", line 184, in enter_raw_repl
    raise PyboardError('could not enter raw repl')
ampy.pyboard.PyboardError: could not enter raw repl

[sebasarango1180]

Hi, has anyone solved this issue?

I'm trying to connect to ESP32 via serial monitor like this: screen /dev/ttyUSB0 115200 (which worked just yesterday), but it is not working now. Also, in another terminal, I've used the command sudo ampy --port /dev/ttyUSB0 put main.py in order to move files from my computer to the device, but it is not working either.

I use Linux Mint 18, and the USB port is working right.

Thanks for any help.

Note 1: The first problem (screen command) was fixed. I solved it by attempting to connect to the ESP32 after having the sensors unplugged. It seems to be like there is an important hardware communication function on IO4 port.

Note 2: The second issue was fixed, too. It was just the data cable. Sorry for the ignorance, but it seems to be like a power-bank cable is not that good for passing data. Ampy is working correctly.

[markserrano915]

@sebasarango1180 One thing I discovered is it's important to state who the board maker is. The ESP32 I got from Makerfocus by Geekworm (https://www.amazon.com/dp/B06XXT9ZQZ/ref=cm_sw_r_cp_apa_WGMCzbWRTQC9Z) fails to load Micropython. However it works with Arduino.

However the one from ESPRESSIF works ( https://www.amazon.com/dp/B01N0SB08Q/ref=cm_sw_r_cp_apa_FIMCzb8HV3CW0) with Micropython. I can list and read files with ampy and rshell.

Edit: Ok it seems I forgot what I stated last time. The Geekworm doesn't load Micropython and won't run ampy on my Macbook. But it is able to load Micropython when it's via Raspberry pi and run ampy. But it still won't run Micropython programs. So it's still a failure for the Geekworm either way

[markserrano915]

I've found a workaround for my ESP32 (from Makerfocus by Geekworm).

Assumptions:

• You've successfully flashed a Micropython firmware.
• Verify by running picocom
• Or verify by running a GUI term like CoolTerm for Mac.
  You should see something like

MicroPython v1.9.1-218-g56f05137 on 2017-07-01; ESP32 module with ESP32
Type "help()" for more information.

The Problem:
So when I run:
ampy --port /dev/tty.wchusbserial1a1210 ls

I get the following error: "could not enter raw repl":
File "/usr/local/lib/python2.7/site-packages/ampy/pyboard.py", line 185, in enter_raw_repl raise PyboardError('could not enter raw repl')

The Workaround:

1. Open /usr/local/lib/python2.7/site-packages/ampy/pyboard.py. Find line 171. Specifically go to the enter_raw_repl method:
   ` 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()`
   

2. Right after the while loop, add a time.sleep(2). So it becomes
   ` 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()
   time.sleep(2)`
   

EDIT: time.sleep(0.5) works as well, below 0.5 I get the dreaded repl error

3. Save and rerun ampy.

You should still be able to run ampy with your working boards because we've only added a delay here.

Other Notes:

1. On a good working board, this is what I see as output (I enabled console logging in the pyboard.py file):

$ ampy --port /dev/tty.SLAB_USBtoUART ls

O
r
>
[

boot.py

2. On a bad board (Maybe "bad" is a misnomer. It's possible the ampy/pyboard program didn't accommodate special cases from some boards), I see this:

mpy --port /dev/tty.wchusbserial1a1210 ls
�
���Ғ�Ҫ�j

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
...
I (2696) cpu_start: Starting scheduler on PRO CPU.
OSError: [Errno 2] ENOENT
MicroPython v1.9.1-218-g56f05137 on 2017-07-01; ESP32 module with ESP32
Type "help()" for more information.
>>>
Traceback (most recent call last):
  File "/usr/local/bin/ampy", line 11, in <module>
    sys.exit(cli())
  ...
  File "/usr/local/lib/python2.7/site-packages/ampy/files.py", line 91, in ls
    self._pyboard.enter_raw_repl()
  File "/usr/local/lib/python2.7/site-packages/ampy/pyboard.py", line 185, in enter_raw_repl
    raise PyboardError('could not enter raw repl')
ampy.pyboard.PyboardError: could not enter raw repl

When I run picocom on both (ie. picocom /dev/tty.wchusbserial1a1210 -b115200), I can see the Micropython prompt, and I can enter REPL mode on both. So I know REPL mode works on BOTH boards.

The issue is in the ampy/pyboard programs, and I think it's because of this piece of code:

        n = self.serial.inWaiting()
        while n > 0:
            self.serial.read(n)
            n = self.serial.inWaiting()

This is essentially like a delay function. The question is should it work the same across all boards?

Edit: I think my theory about the delay function is wrong. Because in both boards, the delay function does nothing. It doesn't make any difference. I think what's happening on my non-working board is it spits out extra text before it goes to the prompt. By adding a time.sleep(), the script will only go to REPL mode after the sleep is done (essentially that's when the extra text has been spitted out. The assumption is the extra text only consumes less than the time seconds stated in the time.sleep() argument)

[ioncodes]

^ This is how I fixed my issue too!

[mcauser]

^ adding a time.sleep(2) after the while in def enter_raw_repl fixed ampy on my ESP8266.

[philwilkinson40]

just to pile on here. The addition of the time.sleep(1) also worked for NODE MCU ESP8266 . Has anyone sent this info to Adafruit?

[mirhec]

Thank you @markserrano915, your solution worked for me as well (Wemos D1 Mini).

[tdicola]

This is probably a good issue to push up to upstream micropython where the pyboard.py code comes from vs. just here in ampy. With all the different boards and hardware available it's hard to pick a good sleep that works for one but doesn't slow down others. Rather than play whack a mole with changing delays to ones which work let's see if upstream micropython might consider a different approach like perhaps a soft reset that skips running main app logic (why the enter raw repl currently does Ctrl-C twice, to stop any running main app).

[silbo]

I had the same issue, I entered with picocom and realised that I had to press twice ctrl-A to enter raw repl. So I modified ampy as following and it started to work for my WEMOS LOLIN32 Lite.

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

But sometimes I still have problems. Might be the delays yea.

[ptixipivipi]

Same issue, same sleep(2) solution working with an ESP32-PICO-KIT V4.

[solarkraft]

Even a delay of 3 seconds does nothing for me.
Wemos D1 Mini, Elementary OS 0.4.1 Loki on the first-gen 13" Xiaomi Mi Notebook Air
I am using Python 3.6 via Anaconda, so I edited /home/paul/miniconda3/lib/python3.6/site-packages/ampy/pyboard.py.

ampy --port /dev/ttyUSB0 mkdir foo
b'\nR;Ltx'
Traceback (most recent call last):
  File "/home/paul/miniconda3/bin/ampy", line 11, in <module>
    sys.exit(cli())
  File "/home/paul/miniconda3/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/paul/miniconda3/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/paul/miniconda3/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/paul/miniconda3/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/paul/miniconda3/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/paul/miniconda3/lib/python3.6/site-packages/ampy/cli.py", line 127, in mkdir
    exists_okay=exists_okay)
  File "/home/paul/miniconda3/lib/python3.6/site-packages/ampy/files.py", line 120, in mkdir
    self._pyboard.enter_raw_repl()
  File "/home/paul/miniconda3/lib/python3.6/site-packages/ampy/pyboard.py", line 193, in enter_raw_repl
    raise PyboardError('could not enter raw repl')
ampy.pyboard.PyboardError: could not enter raw repl

(Takes about 13 seconds)

Running Picocom at the same time gives me outputs like

raw EPL CTR-B o eit
>raw REPL CTRL-B o exi
>raw EPL; CTRLB t eit
                     raw EPL; CTRL-B to exit
                                            >ra REPL; CTRL-B to xit

I guess this would indicate an unreliable connection, but it persists using different cables and text typed through Picocom gets recieved perfectly.

Any ideas?

Entering raw REPL via CTRL-A o my computer works perfectly and gives back a flawless raw REPL; CTRL-B to exit.

[silbo]

@solarkraft may be the code running on the ESP is blocking it somehow or spitting out some stuff.
I would try to reflash it. Meaning to reflash the micropython binary.

I sometimes also get frustrated about ampy not copying over the files and then I just reflash the micropython binary and then it usually works again. I usually copy main.py and then then boot.py after everything else, as if you copy those the system will try to run the code from them and often for me it was failing to copy any other files after I uploaded boot and main.

[luciodj]

time.sleep(2) did it for me as well.
Using a Wemos LOLIN32 and Macbook Pro (Sierra): rshell 0.0.12

[silbo]

@solarkraft any luck getting it working? I noticed that the pyboard.py tries to enter raw repl, then makes a soft reboot and then tries to enter raw repl again. It usually works for me, but now I am testing on Linux Windows and Mac OS, it seems to work on Linux and Windows, but on Mac OS the driver seems to reboot the ESP, so it will fail to enter raw repl. I am still investigating more into it. As I am working on an app to update software on the ESP, so I need to make it reliable.

[garthk]

After some experimentation with my D1 Mini, I found the following made ampy reliable (note: substitute your own port!):

AMPY_PORT=/dev/cu.wchusbserial1410
AMPY_BAUD=115200
AMPY_DELAY=0.5

You can express all these on the command line as options:

ampy -d 0.5 -p /dev/cu.wchusbserial1410 -b 115200 ls

I found it easier to put those three lines into a .env file, then at the beginning of each session:

set -a && . .env && set +a

… after which ampy ls works well.

[silbo]

@garthk thanks for sharing, works for me also on MAC OS. I realized also that the CH304 on MAC OS is reseting my ESP32 all the time when I initiate a serial connection, which sucks and makes ampy not work by default. But adding extra delays makes it work.

[ycx315315]

I solved my issue. by reinstalling the firmware into the board.

[ydnatag]

If the error still happens after trying before solutions, try to add a 100nF capacitor parallel to EN button as is described in Figure 4.

Many development kits haven't this capacitor an it's necessary.

[mrajiullah]

Hi!

I get the same problem when I use ampy to work with pycom fipy device. Its pretty unreliable. Any solution related to ampy and fipy? Thanks.

[devxpy]

@mrajiullah I thought pycom had it's own utils. Do you still need ampy for pycom boards?

Some good news - I've gotten an offer from Jaaga, who wants to sponsor this project. Hopefully, I can devote more time to solving this issue once we have that sorted out.

[neuberfran]

Help me pls
https://forum.micropython.org/viewtopic.php?f=18&t=7095

[kevinkm]

Thanks for markserrano915.
ampy 1.0.7 works on my windows very well, i still have problem on MacOS sierra 10.12.6 through.
I'm able to operate esp32 here but can't connect esp826. ( I'm just talking about the command ampy)
I add "time.sleep(2)" after "while" in pyboard.py like this:
while n > 0:
time.sleep(2)
uninstall the original ampy, then python3 build&install my new ampy, it works now!

[AbhijithHaridas]

I was using another REPEL instance using picocom in the background and I didn't notice it.
I had this same error which leads me to this issue.

The issue went away by closing the other picocom instance

[ropg]

I think I understand it and fixed it, at least for the pyboard.py that lives inside rshell. rshell now has a -s, --suppress-reset switch.

See dhylands/rshell#27 and the Pull Request linked from there.

[chris-88]

I have the same issue on macOS; I was used to running mpy on esp8266 where I could use ampy --port /dev/cu.usbserial-1410 ls but when I moved over to an esp32 ampy wouldn't work at all... a bit of digging and running the ampy --help I realised I could just add a delay 🤦‍♂️ so now I run ampy --delay=1 --port /dev/cu.usbserial-0001 ls and everything runs just fine 😅

[wernersbacher]

Since adding a delay didn't help it to connect, I just connect via Putty to the COM Port, press Strg+C two times to get into the REPL by hand. Then I delete the main.py with the command import uos; uos.remove('main.py') so it doesn't start when I leave the Terminal and then I can copy the files.

[jokerElsa]

I solved my issue. by reinstalling the firmware into the board.

me too i'm still working on this error, reinstall the firmware will fix this, but after flashing once, when you want to flash again this error occurs, so everytime i want to modify the code I have to reinstall the firmware which drives me crazy now......

[lianrenjujishou]

first: os.remove('file running loop')
then: upload file again

[sylvinus]

I can confirm (like many others?) that the sleep(2) suggested above fixes could not enter raw repl on the latest mpremote & mpy, on an ESP32 dev board. This should probably be added :)