search

dhylands / rshell

Remote Shell for MicroPython
MIT License
912 stars 130 forks source link

cp chokes on binary file in -a (ascii) mode #144

Open oclyke opened 3 years ago

oclyke commented 3 years ago

i seem to be running into an issue using the cp command on a particular binary file. other files work fine but this one causes the board and or rshell to stop responding. a full power cycle seems to be necessary to recover

board: rp2040 on SparkFun PiMicro

reproduce:

rshell -a
connect serial /dev/cu.usbmodem0000000000001 115200
cp dist/qwiic_i2c/qwiic_i2c/circuitpy_i2c.mpy /pyboard/qwiic_i2c/circuitpy_i2c.mpy

the circuitpy_i2c.mpy file was cross compiled using v5 of mpy-cross with the flags -march=armv7m and -mno-unicode. the file is attached for reference (the extension has been changed to .png to work alongside github's file attachment tool)

circuitpy_i2c

oclyke commented 3 years ago

edit: after poking this a while longer I suspect that the issue is not with that particular file but rather when trying to overwrite an existing file on the target board. perhaps an error is thrown on the target but not caught by rshell?

oclyke commented 3 years ago

another observation: after entirely erasing the flash memory of the target and re-flashing micropython I proceeded to copy files over one by one. success on 4/5 and then I changed to REPL mode to inspect the filesystem via micropython. at this point I realized that I had forgotten a file. return to rshell and attempt the final copy. same failure mode as before (hang, no error messages etc)

the file that failed did happen to be circuitpy_i2c.mpy once again. because I have now seen the issue on other files as well I am suggesting the issue may occur after using the repl mode

dhylands commented 3 years ago

Did you see this thread over here? https://forum.micropython.org/viewtopic.php?f=15&t=9660#p54175

On Wed, Feb 3, 2021 at 4:24 PM Owen notifications@github.com wrote:

another observation: after entirely erasing the flash memory of the target and re-flashing micropython I proceeded to copy files over one by one. success on 4/5 and then I changed to REPL mode to inspect the filesystem via micropython. at this point I realized that I had forgotten a file. return to rshell and attempt the final copy. same failure mode as before (hang, no error messages etc)

the file that failed did happen to be circuitpy_i2c.mpy once again. because I have now seen the issue on other files as well I am suggesting the issue may occur after using the repl mode

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dhylands/rshell/issues/144#issuecomment-772928070, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA7EDHRSE5JW2CPFEXXDUTS5HSNPANCNFSM4XBWIVIA .

-- Dave Hylands Peachland, BC, Canada http://www.davehylands.com

oclyke commented 3 years ago

thanks for the response Dave. i read through the thread you linked and it felt familiar. i note that the forum user appears to have failed consistently on any file xfer PC --> pico. i am able to get decent results on the main branch of rshell (did not previously know about your 'pico' branch) by using the -a flag. tipped off due to the presence of the -mno-unicode flag in the pico's system config. lately i have uploaded more than ten different bytecode files to the board successfully, and i only seem to have trouble with the one mentioned originally.

~i'll head over to the forums and chime in.~ edit: oops I did not see the second page where everyone exclaimed joyously that the pico branch works wonders. I'll make a note of it in my project.

p.s. overall it's really a pleasure to use rshell - sure beats copy/paste!

oclyke commented 3 years ago

did some testing with the pico branch. made sure to remove the file on the target before copying it over gain (if not i would eventually get errors)

results w/ -a flag BIG SUCCESS - about 5x repetition w/o hangup or error messages

results w/o -a flag consistently (5x) FAILed with this message:

Copying 'Qwiic_Py/micropython/dist/qwiic_i2c/qwiic_i2c/circuitpy_i2c.mpy' to '/pyboard/qwiic_i2c/circuitpy_i2c.mpy' ...
timed out or error in transfer to remote: b'F'
davehylands commented 3 years ago

Can you send me a copy of the circuitpy_i2c.mpy file? You can email it to dhylands@gmail.com

davehylands commented 3 years ago

Nevermind. I see you attached it earlier and named it with a .png extension.

davehylands commented 3 years ago

The issue is that circuit_i2c.mpy is a binary file that happens to contain some 0x03 characters, which are interpreted as Control-C characters.

For the pyboard, rshell performs a setinterrupt(-1) using the micropython.USB_VSP() class, which disables Control-C, but this isn't supported yet on the rp2.

Using the -a option forces the file transfers to use pure ASCII so the Control-C's don't interrupt anything.

davehylands commented 3 years ago

I filed an issue: https://github.com/micropython/micropython/issues/6846 but for now, using -a will be the workaround when needing to transfer binary files which might contain 0x03 characters.

davehylands commented 3 years ago

I've updated rshell on the pico branch to use micropython.kbd_intr(-1) so you should now be able to copy binary files without needing to use the -a mode.