Open markserrano915 opened 7 years ago
Are you disconnecting picocom before trying to use rshell? If not - that's part of the problem. You can't have 2 programs both trying to use the same usb-serial port. If you try, one program will get some of the characters and the other program will get some of the characters.
@dhylands Nope. I don't use picocom and rshell together. It's either I am at picocom terminal or trying ampy / rshell after I have exited out picocom.
The usb cable is connected directly to the MacBook's USB port. I am not using any usb hub. So Macbook has two USB ports. The other one is using a USB hub so I can use other devices, ie iphone, hard drives etc.
Seems like this issue still persists... Will try to upgrade to the latest MicroPython, but this is what i get on a brand new wemos esp32 Lolin32 lite dev board, after freshly installing rshell:
(uPython) ➜ ~ rshell -b 115200 -d --buffer-size=30 -p /dev/tty.wchusbserial1420
Debug = True
Port = /dev/tty.wchusbserial1420
Baud = 115200
User = micro
Password = python
Wait = 0
nocolor = 0
binary = 0
Timing = 0
Quiet = 0
Buffer_size = 30
Cmd = []
Connecting to /dev/tty.wchusbserial1420 ...
----- About to send 286 bytes of code to the pyboard -----
def test_buffer():
"""Checks the micropython firmware to see if sys.stdin.buffer exists."""
import sys
try:
_ = sys.stdin.buffer
return True
except:
return False
output = test_buffer()
if output is None:
print("None")
else:
print(output)
-----
b'\xd9:\xc2A0\x8c\xdcE\xc9v\xba\xc2A0I\xfdd.\x97\x82\xc2\xc1\xb0i\xcd\xc1_\xe4\xae\x97\x82\xc2\xc10,\xa8\xd6E\xc9v\xba\xc2A0i\xc1_\xa4\xae\x97\x82\xc2\xc10\r\xa1\xeb\x8b\x95:\xc4R\x8a\t\x1a\xb1\xbdc\xeb"\xa5v\'fH\xec+\xd1:\xc2\xcdf\xe6\x16\x821bb\x95\xb9i\xb4C!\xeb\x85d\xba\xc2\xcd\xe6\x96A0L,\x89\x95n\xbaS\x9a2\x8d!\xeb\x85\xd1:\xc2\xd10\xb0\x13\x820bb\x95\xb9:\xb0C!\xeb\x85d\xba\xc2Q\xb0\xba\xc20\xb0b\xa2\x95\xf9:L\xca9\xb2C\xa1\x96\x8b\xc9\xe5 \xc2\xd10\xb0\x13YcSH\xf8\x1b[0;32mI (349) cpu_start: Pro cpu up.\x1b[0m\r\n\x1b[0;32mI (349) cpu_start: Single core mode\x1b[0m\r\n\x1b[0;32mI (350) heap_init: Initializing. RAM available for dynamic allocation:\x1b[0m\r\n\x1b[0;32mI (353) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (359) heap_init: At 3FFD4D08 len 0000B2F8 (44 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (366) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (372) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (378) heap_init: At 4008FB00 len 00010500 (65 KiB): IRAM\x1b[0m\r\n\x1b[0;32mI (384) cpu_start: Pro cpu start user code\x1b[0m\r\n\x1b[0;32mI (178) cpu_start: Starting scheduler on PRO CPU.\x1b[0m\r\nOSError: [Errno 2] ENOENT\r\nMicroPython v1.9.2-283-gdba3796e on 2017-10-27; ESP32 module with ESP32\r\nType "help()" for more information.\r\n>>> '
Traceback (most recent call last):
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1185, in connect
ip_address = socket.gethostbyname(port)
socket.gaierror: [Errno 8] nodename nor servname provided, or not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/nmistry/.virtualenvs/uPython/bin/rshell", line 11, in <module>
sys.exit(main())
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/command_line.py", line 4, in main
rshell.main.main()
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 2658, in main
real_main()
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 2620, in real_main
connect(args.port, baud=args.baud, wait=args.wait, user=args.user, password=args.password)
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1191, in connect
connect_serial(port, baud=baud, wait=wait)
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1215, in connect_serial
dev = DeviceSerial(port, baud, wait)
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1436, in __init__
Device.__init__(self, pyb)
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1262, in __init__
self.has_buffer = self.remote_eval(test_buffer)
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1353, in remote_eval
return eval(self.remote(func, *args, **kwargs))
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1331, in remote
self.pyb.enter_raw_repl()
File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/pyboard.py", line 187, in enter_raw_repl
raise PyboardError('could not enter raw repl')
rshell.pyboard.PyboardError: could not enter raw repl
(uPython) ➜ ~
Thanks for the report. I never appreciated all the crap being sent back during boot up.
I noticed this: OSError: [Errno 2] ENOENT
Which is probably coming from your boot.py. I suspect that you'll need to fix that first before rshell will work properly.
Once you've got that dealt with you may also need to add the -a option in order to transfer files.
On Mon, Feb 26, 2018 at 1:46 AM Nicholas Mistry notifications@github.com wrote:
Seems like this issue still persists... Will try to upgrade to the latest MicroPython, but this is what i get on a brand new wemos esp32 Lolin32 lite dev board, after freshly installing rshell:
`(uPython) ➜ ~ rshell -b 115200 -d --buffer-size=30 -p /dev/tty.wchusbserial1420 Debug = True Port = /dev/tty.wchusbserial1420 Baud = 115200 User = micro Password = python Wait = 0 nocolor = 0 binary = 0 Timing = 0 Quiet = 0 Buffer_size = 30 Cmd = [] Connecting to /dev/tty.wchusbserial1420 ... ----- About to send 286 bytes of code to the pyboard ----- def testbuffer(): """Checks the micropython firmware to see if sys.stdin.buffer exists.""" import sys try: = sys.stdin.buffer return True except: return False output = test_buffer() if output is None: print("None") else: print(output)
b'\xd9:\xc2A0\x8c\xdcE\xc9v\xba\xc2A0I\xfdd.\x97\x82\xc2\xc1\xb0i\xcd\xc1\xe4\xae\x97\x82\xc2\xc10,\xa8\xd6E\xc9v\xba\xc2A0i\xc1\xa4\xae\x97\x82\xc2\xc10\r\xa1\xeb\x8b\x95:\xc4R\x8a\t\x1a\xb1\xbdc\xeb"\xa5v'fH\xec+\xd1:\xc2\xcdf\xe6\x16\x821bb\x95\xb9i\xb4C!\xeb\x85d\xba\xc2\xcd\xe6\x96A0L,\x89\x95n\xbaS\x9a2\x8d!\xeb\x85\xd1:\xc2\xd10\xb0\x13\x820bb\x95\xb9:\xb0C!\xeb\x85d\xba\xc2Q\xb0\xba\xc20\xb0b\xa2\x95\xf9:L\xca9\xb2C\xa1\x96\x8b\xc9\xe5 \xc2\xd10\xb0\x13YcSH\xf8\x1b[0;32mI (349) cpu_start: Pro cpu up.\x1b[0m\r\n\x1b[0;32mI (349) cpu_start: Single core mode\x1b[0m\r\n\x1b[0;32mI (350) heap_init: Initializing. RAM available for dynamic allocation:\x1b[0m\r\n\x1b[0;32mI (353) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (359) heap_init: At 3FFD4D08 len 0000B2F8 (44 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (366) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (372) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (378) heap_init: At 4008FB00 len 00010500 (65 KiB): IRAM\x1b[0m\r\n\x1b[0;32mI (384) cpu_start: Pro cpu start user code\x1b[0m\r\n\x1b[0;32mI (178) cpu_start: Starting scheduler on PRO CPU.\x1b[0m\r\nOSError: [Errno 2] ENOENT\r\nMicroPython v1.9.2-283-gdba3796e on 2017-10-27; ESP32 module with ESP32\r\nType "help()" for more information.\r\n>>> ' Traceback (most recent call last): File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1185, in connect ip_address = socket.gethostbyname(port) socket.gaierror: [Errno 8] nodename nor servname provided, or not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "/Users/nmistry/.virtualenvs/uPython/bin/rshell", line 11, in sys.exit(main()) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/command_line.py", line 4, in main rshell.main.main() File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 2658, in main real_main() File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 2620, in real_main connect(args.port, baud=args.baud, wait=args.wait, user=args.user, password=args.password) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1191, in connect connect_serial(port, baud=baud, wait=wait) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1215, in connect_serial dev = DeviceSerial(port, baud, wait) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1436, in init Device.init(self, pyb) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1262, in init self.has_buffer = self.remote_eval(test_buffer) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1353, in remote_eval return eval(self.remote(func, *args, **kwargs)) File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/main.py", line 1331, in remote self.pyb.enter_raw_repl() File "/Users/nmistry/.virtualenvs/uPython/lib/python3.6/site-packages/rshell/pyboard.py", line 187, in enter_raw_repl raise PyboardError('could not enter raw repl') rshell.pyboard.PyboardError: could not enter raw repl (uPython) ➜ ~`
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/dhylands/rshell/issues/27#issuecomment-368405722, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHyDNC2cFfMvz7ufkX5MyJ8MSi_wFyNks5tYlM4gaJpZM4OCq4b .
-- Dave Hylands Peachland, BC, Canada http://www.davehylands.com
I'm having the same issue as the OP: a brand new Wemos D1 Mini flashed with MicroPython 1.9.3 shows the same garbage before getting to the REPL (via plain ol' screen
in my case):
rll��|�l�|�d�c|����{�c�c��no�lgg���cp��l{drlp�o��dbo�|�ldc��gg�d��l`�nnd�l`'s���o�sd``�o��c�ol���no��dx�n�r�����c'�|$�c��oo�l�d`�gnd`gsǓ�orl p�o�s�������bo�|��c��og�d`�gd`o;���g�`s��o�l �l��|��rg#��l�b�dc쌜���dc�drlll��|��{oc��ld�x{�c�#䄜��b#��$sl�l��|��rgc��d���c�b�Ĝ��b�lcd����o�r��g|�dlll`��s�d�l�d`��{�l�l�l`��s�d���ll`rl��;d����c��c�ccs�{c��'�o�l��l�l��dd������l�o����cdd�rp���cl�c;lrls�o�����o����c������l#lsc��㌇l{d��do�psd�d��|����#4 ets_task(40100130, 3, 3fff837c, 4)
OSError: [Errno 2] ENOENT
MicroPython v1.9.3-8-g63826ac5c on 2017-11-01; ESP module with ESP8266
Type "help()" for more information.
>>>
As discussed, this causes rshell
to fail – I eventually get the same stack trace:
Debug = True
Port = /dev/tty.wchusbserial144230
Baud = 115200
User = micro
Password = python
Wait = 0
nocolor = 0
binary = 0
Timing = 0
Quiet = 0
Buffer_size = 512
Cmd = []
Connecting to /dev/tty.wchusbserial144230 ...
----- About to send 286 bytes of code to the pyboard -----
def test_buffer():
"""Checks the micropython firmware to see if sys.stdin.buffer exists."""
import sys
try:
_ = sys.stdin.buffer
return True
except:
return False
output = test_buffer()
if output is None:
print("None")
else:
print(output)
-----
b'rl\x00l\x9c\x9f|\x00\x8cl\xe0|\x03\x0c\x0c\x0c\x8c\x0cd\xe4\x04c|\x8f\xc3\x02\xec\x13\x93s\x9bc\x8c\x0cc\x8c\xf3nn\x9flog\x9c\xe3\xe4\x04b\x1cp\xe4\x87l{d{$p\xfbo\xe0\x10\x03\x0c\x0c\x83\x04d\x04\x04\x0c\x0c\x0c\x0cc\x04n\xe3|\x03\xecll\x0c\x0c\x04b\x84\xfbog\xef\x00l\x84\x8fd`\x03\x90\x1b\x1bogl\x8cd`\x03\x0f\x03o{\x87\x92\x93g\x04\x04\x9b{l`\x02`\xf3g\x04\x04\x04\x9f\xe0c\x82gl\x84\x04\x84\xfboo\xef\x00\x0c\x8e\x07lp\xfbo\xe0\x10\x02\x0c\x0cs\x84\x9c\x9c\xe3\xe0\x0c\x0c\x0c\x0c#\x04o\xe3|\x03l\x0c\x0c\x0c\x8fb\x84\xfbog\xef\x00l\x8c\x04d`\x03\x98\x13\x13nn\x04l`\x03\x07\x02gs\x8e\x93\x9bo\x0c\x0cr\x03l \x03p\xfbo\xe0\x10\x02\x0c\x0cs\x84\x9c\x9c\xe3\xe0\x0c\x87\x87\x0c#\x04o\xe3|\x03\xec\x8c\x0c\x8e\x04b\x84\xfbog\xef\x00\x0c\x0cd`\x03\x90\x13\x1boo\x0cl`\x03\x07\x03n{\x8f\x9b\xdbg\x0c\x0c\x93\x13d`\x03\x0f;\x92\x93g\x04\x04\x9b\x1bl`\x02\x07\xfc\x80\x04d\x9c\x9f|\xff\x82\x13ssnc\x8f\x8c\x0cl\xec\x13\x04\x04c\xecl\x0cc\xec\x84\x9c\x9c\xe3\xe3l\x0c\x0c\x0cc\x04\x8fdsl\x07l\x0cl\x9c\x9f|\xff\x83\x1b;rgc\x8e\x84dd\x9c8\x13{\x82c\xec\x8c\x04b\xe4\x84\x9c\x9c\xe2\x03b\x03\x0c\x04b\xe4\x04\x8flsd\x07\x8c\x0cd\x9c\x9f|\xff\x83\x1b;rgc\x8e\x84d\x04\x9c\x1c\x8c\x0c\x87c\x8c\x0c\x04b\xe4\x84\x9c\x9c\xe2\x03\x12\x0c\x0c\x04b\xe4dc\x0el\x84\xe2\x03\xec\x13\x83n\xe4\x9b{\xc3\xf2g|\xe4\x0cd\x04d$l`\x02\x84\xe2s\x9bd\x84d\x12\x8c\x0c\x0c\x0cl`\x03\x8c\xe3{\x92l\xecl\x13\x8c\x0c\x04\x04d`\x03\x8c\xe3;\x93l\x0c\x8e\x9f\x00\x84\x04\x04ll`\x02{d\xc7\x83sl\x84\x9f\xe2\x8cb\x0c\x8c\x8cb\x84c\x04cr\x03\x02\xec\xc7s\x04\x13\x13b\xe4\xfbo\xee\x80\x12gg\xe3\x10\x03\x04\x03$\x9b\xfb\x02\x0cl\x0c\x84\x04d\xc4\x87ll\x87\x1f\x83\x8c\x84\x84\xe4\x8f\x07l\x80\x02g\xfc\x00\x8c\x9e\xe3\x8cc\x04l\x0cl\x87sx\x0c\x04\x03\x03\x84\x9f\xe2\x8c#\x0cl\x0c\x84b\x1cslsl{\xf2g\x9c\xe3\x00\x84\x04\xe4\xfbo\x9c\x9f\x80\x80\x03c\x8f\xe0\xec\xe4\xe3\x8c\xeclblsc\x04\x84\x8f\x1f\xe3\x8c\x87l{d\x03\x83\x83\x03do\x9cp{d\x07\xec\x0cd\x9c\x9f|\xff\x83\x1b\x9a\xff#4 ets_task(40100130, 3, 3fff837c, 4)\r\nOSError: [Errno 2] ENOENT\r\n\r\nMicroPython v1.9.3-8-g63826ac5c on 2017-11-01; ESP module with ESP8266\r\nType "help()" for more information.\r\n>>> '
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1185, in connect
ip_address = socket.gethostbyname(port)
socket.gaierror: [Errno 8] nodename nor servname provided, or not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/bin/rshell", line 11, in <module>
sys.exit(main())
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/command_line.py", line 4, in main
rshell.main.main()
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 2658, in main
real_main()
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 2620, in real_main
connect(args.port, baud=args.baud, wait=args.wait, user=args.user, password=args.password)
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1191, in connect
connect_serial(port, baud=baud, wait=wait)
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1215, in connect_serial
dev = DeviceSerial(port, baud, wait)
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1436, in __init__
Device.__init__(self, pyb)
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1262, in __init__
self.has_buffer = self.remote_eval(test_buffer)
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1353, in remote_eval
return eval(self.remote(func, *args, **kwargs))
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/main.py", line 1331, in remote
self.pyb.enter_raw_repl()
File "/Users/abach/.local/share/virtualenvs/apps3-QGfBTaMN/lib/python3.6/site-packages/rshell/pyboard.py", line 187, in enter_raw_repl
raise PyboardError('could not enter raw repl')
rshell.pyboard.PyboardError: could not enter raw repl
@dhylands, re: your comment about this being an issue in boot.py
, this occurs even with the default boot.py
that MicroPython uses:
# This file is executed on every boot (including wake-boot from deepsleep)
#import esp
#esp.osdebug(None)
import gc
#import webrepl
#webrepl.start()
gc.collect()
Not sure what to fix (or whether anything can be "fixed" at this level)?
I think that the error is this one:
OSError: [Errno 2] ENOENT
You need to resolve that before rshell will connect. This is most likely due to a missing main.py (just a guess - I don't have an ESP32)
I experienced this problem connecting to a Wemos D1 Mini Lite from a Macintosh. Adding a short delay in the enter_raw_repl() function in pyboard.py, as described at https://forum.micropython.org/viewtopic.php?t=3217#p19117 seems to fix the problem.
The only thing that worked for me was changing the file "pyboard.py" in Python_path / Lib / site-packages / (for Python3, first change the extension to the adafruit_ampy-X.X.X-py.X.X file from .egg to .zip and unzip, edit the file and then change the extension again). In the "pyboard.py" file, you have to add a pause in the definition of the "enter_raw_repl" function, after the line self.serial.write (b'\r\x03\x03') add time.sleep (.2)
It worked for me in Windows10 with a wemos_oled_18650_battery board
I am sorry for my bad english
Are you talking about ampy or rshell? Your comment mentions editing an ampy file.
My apologies, I mixed the themes. I have the same problem: "Could not enter raw repl" but when I use ampy from cmd on Windows. Anyway, I suppose that in the case of rshell, in the case of using python3 there is also an "egg" package with a "pyboard.py" file to edit, or it will be free in the "site-packages" folder, such as in python2
The only thing that worked for me was changing the file "pyboard.py" in Python_path / Lib / site-packages / (for Python3, first change the extension to the adafruit_ampy-X.X.X-py.X.X file from .egg to .zip and unzip, edit the file and then change the extension again). In the "pyboard.py" file, you have to add a pause in the definition of the "enter_raw_repl" function, after the line self.serial.write (b'\r\x03\x03') add time.sleep (.2)
This works!
I have the same issue with using ampy with my NodeMCU ESP8266, got the "could not enter raw repl" error on all my windows 10 machines at work. It works fine on OSX. But adding this line made it work! Thanks Sansanito!!
I like rshell very much. but i meet the issue with ESP32- WROOM-32. I must hardware reset the ESP32 each time before want connect to ESP32 ,otherwise,would display "could not enter raw repl" . but for ESP8266, It's ok.
I added below code in "pyboard.py" .The function just simulates the hareware reset before connection.
self.serial = serial.Serial(device, baudrate=baudrate, interCharTimeout=1)
self.serial.setDTR(0) #IO0=HIGH
time.sleep(0.02)
self.serial.setRTS(1) #EN=LOW
time.sleep(1)
self.serial.setDTR(1) #IO0=LOW
time.sleep(0.02)
self.serial.setRTS(0) #EN=HIGH
time.sleep(1)
self.serial.setDTR(0) #IO0=HIGH
#------ added to here--------
break
The delay time parameters in the code sometimes just make ESP32 work, and ESP8266 does not. I adjusted the delay time parameters, and it does work on ESP32 and ESP8266 DEVKITV1 both。 Maybe the delay time parameters depend on the capacity on EN pin and IO0 pin of the ESP.
sorry for my poor english.
simplified to below code can reset ESP board when connecting, and no need hardware reset when reconnecting to ESP board on ESP8266 and ESP32 board.
in init() of class pyboard.py file.
self.serial = serial.Serial(device, baudrate=baudrate, interCharTimeout=1)
self.serial.setRTS(1) #EN=LOW time.sleep(0.01) self.serial.setRTS(0) #EN=HIGH
break
On my system runs: rshell --version
→ 0.0.16
Used board: wemos lolin d32
On my system rshell also works very unreliable.
After I put a simple blink Test on the board rshell -b 115200 -p /dev/ttyUSB0 rsync . /pyboard
exits with the following error:
Connecting to /dev/ttyUSB0 ...
b'OK\r\nets Jun 8 2016 00:22:57\r\n\r\nrst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)\r\nconfigsip: 0, SPIWP:0xee\r\nclk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00\r\nmode:DIO, clock div:2\r\nload:0x3fff0018,len:4\r\nload:0x3fff001c,len:4732\r\nload:0x40078000,len:7496\r\nload:0x40080400,len:5512\r\nentry 0x4008114c\r\n\x1b[0;33mW (86) boot: PRO CPU has been reset by WDT.\x1b[0m\r\n\x1b[0;33mW (86) boot: WDT reset info: PRO CPU PC=0x40080200\x1b[0m\r\n\x1b[0;33mW (86) boot: WDT reset info: APP CPU PC=0xb2dd3d3b\x1b[0m\r\n\x1b[0;32mI (463) cpu_start: Pro cpu up.\x1b[0m\r\n\x1b[0;32mI (463) cpu_start: Single core mode\x1b[0m\r\n\x1b[0;32mI (463) heap_init: Initializing. RAM available for dynamic allocation:\x1b[0m\r\n\x1b[0;32mI (467) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (473) heap_init: At 3FFC4F68 len 0001B098 (108 KiB): DRAM\x1b[0m\r\n\x1b[0;32mI (479) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (485) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM\x1b[0m\r\n\x1b[0;32mI (492) heap_init: At 40091604 len 0000E9FC (58 KiB): IRAM\x1b[0m\r\n\x1b[0;32mI (498) cpu_start: Pro cpu start user code\x1b[0m\r\n\x1b[0;32mI (68) cpu_start: Starting scheduler on PRO CPU.\x1b[0m\r\nalloc_emergency_exception_buf done\r\nLet\'s start blinking\r\nMicroPython v1.9.4-674-g27ca9ab8b on 2018-10-24; ESP32 module with ESP32\r\nType "help()" for more information.\r\n>>> '
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1197, in connect
ip_address = socket.gethostbyname(port)
socket.gaierror: [Errno -2] Name or service not known
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/rshell", line 11, in <module>
load_entry_point('rshell==0.0.16', 'console_scripts', 'rshell')()
File "/usr/local/lib/python3.6/dist-packages/rshell/command_line.py", line 4, in main
rshell.main.main()
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 2730, in main
real_main()
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 2692, in real_main
connect(args.port, baud=args.baud, wait=args.wait, user=args.user, password=args.password)
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1203, in connect
connect_serial(port, baud=baud, wait=wait)
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1227, in connect_serial
dev = DeviceSerial(port, baud, wait)
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1473, in __init__
Device.__init__(self, pyb)
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1285, in __init__
self.root_dirs = ['/{}/'.format(dir) for dir in self.remote_eval(listdir, '/')]
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1390, in remote_eval
return eval(self.remote(func, *args, **kwargs))
File "/usr/local/lib/python3.6/dist-packages/rshell/main.py", line 1368, in remote
self.pyb.enter_raw_repl()
File "/usr/local/lib/python3.6/dist-packages/rshell/pyboard.py", line 193, in enter_raw_repl
raise PyboardError('could not enter raw repl')
rshell.pyboard.PyboardError: could not enter raw repl
Steps to reproduce the problem:
esptool.py --chip esp32 erase_flash
esptool.py --baud 600000 --chip esp32 --port /dev/ttyUSB0 write_flash -z 0x1000 esp32-20181024-v1.9.4-674-g27ca9ab8b.bin
main.py
on the board with rshell -b 115200 -p /dev/ttyUSB0 rsync . /pyboard
main.py
runs.main.py
on the board again with rshell -b 115200 -p /dev/ttyUSB0 rsync . /pyboard
ampy
shows similar behavior (see https://github.com/adafruit/ampy/issues/66#issue-374198286).
After that if i erase the flash and flash the micropython firmware again everything works as expected until i uploaded main.py
of my blinking example.
At the same time mpfshell
works without complaining. Here a quick sample session i started right after invoking rshell
:
johannes:~/iot/esp/Micropython/MyExamples/TimerTest % mpfshell -c "open ttyUSB0"
Connected to esp32
** Micropython File Shell v0.8.1, sw@kaltpost.de **
-- Running on Python 2.7 using PySerial 3.4 --
mpfs [/]> cat boot.py
# This file is executed on every boot (including wake-boot from deepsleep)
#import esp
#esp.osdebug(None)
#import webrepl
#webrepl.start()
mpfs [/]> cat main.py
import machine
from machine import Pin
from machine import Timer
import micropython
micropython.alloc_emergency_exception_buf(256)
print("alloc_emergency_exception_buf done")
io23 = Pin(23, Pin.OUT)
io05 = Pin(5, Pin.OPEN_DRAIN)
io23.value(1)
io05.value(0)
timer1 = Timer(-1)
timer1.init(mode=Timer.PERIODIC, period=100, callback=lambda t:io23.value(not io23.value()))
timer2 = Timer(-2)
timer2.init(mode=Timer.PERIODIC, period=100, callback=lambda t:io05.value(not io05.value()))
print("Let's start blinking")
mpfs [/]>
I had the same problem. When looking into it I found that the ili9341 driver I use does not deinit cleanly, which causes the following behaviour on Ctrl-D (soft reset):
Traceback (most recent call last):
File "ili9XXX.py", line 244, in deinit
MemoryError: memory allocation failed, heap is locked
MPY: soft reboot
Single buffer
assertion "ATB_GET_KIND(block) == AT_HEAD" failed: file "../../py/gc.c", line 591, function: gc_free
abort() was called at PC 0x401ea00f on core 0
ELF file SHA256: 0000000000000000
Backtrace: 0x40099224:0x3ffd4590 0x4009964d:0x3ffd45b0 0x401ea00f:0x3ffd45d0 0x400d34ee:0x3ffd4600 0x400d2bcd:0x3ffd4620 0x40106eaf:0x3ffd4640 0x400ffdc2:0x3ffd4660 0x4012cd55:0x3ffd4680 0x4012dbf3:0x3ffd46a0 0x40100925:0x3ffd46d0 0x4015e223:0x3ffd4700 0x400e44d5:0x3ffd4720 0x400e02f1:0x3ffd4740 0x400e0432:0x3ffd4760 0x400e5e80:0x3ffd4780 0x400e5ebb:0x3ffd47b0 0x400eb978:0x3ffd47d0 0x400e04ba:0x3ffd48b0 0x400eedb5:0x3ffd48f0 0x400e46a4:0x3ffd4990 0x400e02f1:0x3ffd49c0 0x400e0432:0x3ffd49e0 0x400eeaa1:0x3ffd4a00 0x400e46a4:0x3ffd4aa0 0x400e02f1:0x3ffd4ad0 0x400e0432:0x3ffd4af0 0x400eeaa1:0x3ffd4b10 0x400e46a4:0x3ffd4bb0 0x400e02f1:0x3ffd4be0 0x400e2c32:0x3ffd4c00 0x400e02f1:0x3ffd4c50 0x400e0432:0x3ffd4c70 0x400ea46e:0x3ffd4c90 0x400e9919:0x3ffd4ce0 0x400e02f1:0x3ffd4d00 0x400ee9e1:0x3ffd4d20 0x400e46a4:0x3ffd4dc0 0x400e02f1:0x3ffd4df0 0x400e031a:0x3ffd4e10 0x4015dc7e:0x3ffd4e30 0x4015e061:0x3ffd4ec0 0x4015e0cb:0x3ffd4ee0 0x400f8587:0x3ffd4f00 0x40095d25:0x3ffd4f30
Rebooting...
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x17 (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:5092
load:0x40078000,len:14024
load:0x40080400,len:3760
entry 0x40080638
Double buffer
ILI9341 initialization completed
FT6X36 touch IC ready (fw id 0x10 rel 1, lib 300E)
MicroPython v1.14-457-g3bf6c7f12-dirty on 2021-05-23; M5Stack Core2 with ESP32
Type "help()" for more information.
>>>
The problem is that rshell, via pyboard, does the following when it goes to the raw REPL mode:
raw REPL; CTRL-B to exit\r\n>
raw REPL; CTRL-B to exit\r\n
Apparently this soft-reset maintains the raw REPL status and does not revert to friendly REPL. But since my ESP32 crashes on the soft reset because the ili9341 driver doesn't cleanly unload, it doesn't get a raw REPL when it expects one. You'll notice the second time it looks for the raw REPL thing, it looks without the >
prompt. That is significant because that is then expected by exec_raw_no_follow
(line 230), so just removing the last two steps doesn't work.
The soft reset is probably to unload anything that might be hogging memory. One might argue that this is a broken state on the board and that therefore rshell doesn't need to work, but this will lock out everyone that gets their board in a state where the soft-reset does not happen cleanly, although they have a perfectly working raw REPL.
So I built a command line option -s
, --suppress-reset
to both pyboard and rshell. It does what you might expect and lets users connect to boards that are not exhibiting the correct soft-reboot behaviour. See the Pull Request for details.
If you want to try if -s
solves your problems:
python -m pip install git+https://github.com/ropg/rshell.git
This is actually an issue and a response I posted on the ampy project. See ESP8266 Micropython "Could not enter raw repl" #19
I am creating this issue because it's exactly the same with rshell. This is for reference and workaround purposes.
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 rshell commands without issues!
My immediate solution is:
Some interesting observations: