raspberry pi - looking for hexlify - hang

[diginfo]

Just installed rshell on a raspberry pi and although I can connect to the device using screen, when I run rshell it just prints "looking for hexlify" (or something similar) and then hangs.

That also seems to lockup the device which then cannot be accessed at all unless it is hard-reset.

Any suggestions ?

[dhylands]

This usually means that there is a problem with the device not being able to get to the REPL.

What type of device are you using?

Are you using USB on the Pi or serial from the header?

[dhylands]

Whenever I have issues connecting with rshell, I usually then try using screen or picocom and verify that I can a REPL. If you can't get a REPL using a terminal program, then rshell won't be able to talk to the board either.

[diginfo]

Hi

I can connect to the device using screen

• no problem to get a repl using screen,

Device is esp8266

[dhylands]

Make sure that you don't have screen (or any other program that might be using the serial port) running at the same time as you're trying to use rshell.

I have a Huzzah Feather ESP8266 plugged into one of the USB ports on my RPi 3B+ and it seems to be working fine:

pi@gateway:~$ rshell -p /dev/ttyUSB0
Using buffer-size of 32
Connecting to /dev/ttyUSB0 (buffer-size 32)...
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /boot.py/
Setting time ... Mar 22, 2019 23:52:05
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.
/home/pi> 

[dhylands]

Are you connecting via USB or via the serial port on the header?

[diginfo]

Thanks, I have rebooted the rpi before attempting to connect using rshell, have also done a kill -9 on the SCREEN pid, makes no difference.

No onboard USB, I am connecting via silicon labs USB > Serial adapter, same as I use on my Macs.

Problem is RPI and ESP8266 are in the UK and I am in Singapore, so getting a hard reset done on the ESP8266 involves sending an email to someone in the UK to press the reset button :-)

[diginfo]

What if "Testing if ubinascii.unhexlify exists" search fails, does it give up or just keep trying forever ??

[dhylands]

What if "Testing if ubinascii.unhexlify exists" search fails, does it give up or just keep trying forever ??

It's a one-shot thing. It sends the commands and waits for a response.

If anybody other program has the serial port open then some of the response will go to rshell and some of the response will go to the other program.

And just to clarify. The USB-to-serial adapter is plugged into the RPi and the TTL serial side connects to the ESP8266. And the ESP8266 doesn't have any onboard USB-to-serial chip.

rshell has a -d option which causes more output to be produced, but I'm not sure it will help in this case.

[diginfo]

Thanks Dave;

So if it does not get a response it will wait forever, it does not timeout ?

Yes, TTL side is connected to ESP8266 (ESP12-S), no onboard USB Chip, this is not one of those wee-mini etc development boards, the esp12-S, there is no USB device onboard at all.

works 100% of the time using linux screen command, but just hangs when attempting connection with rshell.

[dhylands]

This is probably one of those cases where we'd need to connect a logic analyzer up and see what's actually going back and forth.

Or perhaps use usbmon. I wrote a blog post about capturing data using usbmon: https://blog.davehylands.com/capturing-usb-serial-using-wireshark/

[diginfo]

Thanks;

Yes, would be simple if both were on my bench here in Singapore, but I am in Singapore and the RPI and ESP8266 are in the UK

[dhylands]

I think that older versions of the esp8266 firmware didn't support Control-C over the REPL, and that means that if a program is running when you connect rshell, then it won't enter into the REPL (which prevents rshell from working)

Another test to try is to create a small file on the pi, say hello.py that contains:

print('Hello World')

and then try using pyboard.py to run that. I believe that the syntax is:

pyboard.py --device /dev./ttyUSB0 hello.py

[dhylands]

I just uploaded version 0.0.21 of rshell which now tries to get a REPL prompt for several seconds before continuing.

it turns out some of the devices reset when you open the serial port, and the verbage printed out at the beginning can confuse rshell.

[diginfo]

Dave;

This was deployed in 2017, so it may very well be pre-hexlify.

But it's very difficult for me to debug being 10,000km away, last time I ran rshell on the connected 8266, it was unable to connect as reported, but also it needed the device to be hard reset before I was able to access the repl again. I have to send an email to someone to reset it, and that might take 2 minutes or 4 hours depending upon whether they are there or not.

I will try this again tomorrow and see if I can access using the new version, but I will only get one shot :-)

[diginfo]

OK, just managed to connect using linux screen, but latest version (0.21) of rshell cannot.

Also, I can confirm that it is running 1.93:

MicroPython v1.9.3-dirty on 2018-01-07; ESP module with ESP8266
Type "help()" for more information.
>>> 

Is there anyway to make it backward compatible as I am unable to upgrade the 1.93 firmware ?

[perbu]

Hi. I just had the same issue. Here are some of my notes.

I have this: MicroPython v1.12-337-g312c69949 on 2020-04-05; ESP32 module (spiram) with ESP32

and I've just had a little session where rshell failed to get pass the hexlify check. What seems to have been blocking it was boot.py. boot.py was looking for a certain wifi and busy in the following loop:

        while not sta.isconnected():
            time.sleep(0.1)
            print('.', end='')

So I connect via screen, pressed ^c and closed down screen. Still rshell would not connect. Conncted back via screen I could see error messages being injected into the prompt. These messages have ANSI sequences.

I deactivated the wifi interface, the messages stopped appearing and now rshell seems to be working fine.

Deleted boot.py and now everything is hunky dory.

[dhylands]

Yeah - rshell uses pyboard.py which sends Control-C & Control-D sequences to soft reset the processor. This happens several times just to get rshell started,

IIRC Micropython always executes boot.py on soft-reset, but doesn't execute main.py when rebooting into the raw-REPL.

So the solution would be to move the wifi connection code from boot.py into main.py. boot.py was intended just for doing hardware setup (i.e. adding flash drive, configuring USB) and not doing things like connecting to wifi.

Another possibility is to use a GPIO pin to indicate booting in "rshell mode" versus "run" mode and have your code in boot.py query the GPIO pin.

[perbu]

Now everything makes sense. Thanks for taking the time to explain.