Xmodem tutorial for dwelch67's bootloaders? [SOLVED]

[gaidal]

I installed lszrz but couldn't figure out how to use sx to send to the bootloader. Found a few examples online (very few) and tried to use the same parameters, but it would just print one line and freeze the terminal.
Then I found a tool called xmUtil (https://github.com/Vassius/xmUtil.git) that worked, and used it to smoothly start several smaller programs on the pi, but once I started to use functions in my programs and the file sizes went up to 32k-ish (for instance Baking PI - OK03), it didn't work anymore. It sends 9-10 packets, then says for each packet that it didn't receive ACK.

I'm sure this xmodem thing is something really trivial since I can hardly seem to find descriptions or examples at all!
Anyway, I've been moving my poor SD card back and forth for hours now and am quite eager to get back to using a bootloader eventually.

Would anyone kindly like to give some advice or point to useful information?

[dwelch67]

apt-get install minicom

then

minicom -s

it is a clunky user interface but it works. make sure you set the port for the uart /dev/ttyUSB0 or whatever, and turn off hardware flow control. then save as default or save as and give it a name, for example usb0 (I usually also disable the bell on transfer complete, and empty the modem strings for init and hang up so that they dont get sent out...(a space backspace enter k space backspace enter)

then exit minicom (ctrl-a then q)

then restart minicom (At a minimum I have always needed to do this to actually turn off flow control YMMV).

minicom usb0

and now to send a file, in minicom

ctrl-a then s
down arrow to xmodem
then I usually just hit enter and then type in the file name. you will find life is easiest if you put your .bin file in your home directory then you dont have to learn to surf through directories using minicoms user interface.

after you have sent the file once, then the next time it is ctrl-a then s then enter twice, it remembers the file name after the first time.

I believe in minicom (alt-a then o or do the minicom -s thing) it shows the lrzsz command lines so if you want to run sz directly use the matching command line...

David

[gaidal]

Works like a charm!
Very helpful, me and my SD card thank you!

Some notes:
<C-a s enter enter> isn't enough to resend a file, since this would open the zmodem menu. At least I need <C-a s down down enter enter>. Also, this is only until you exit the program, it unfortunately doesn't save current directory and file between runs.

To disable the "Cannot create lockfile" warning that showed after sending each file when running minicom as a normal user, I had to change the permissions for /run to 777. I think it's /var/run on other systems, Arch Linux symlinks that to /run. Not sure if this is a smart thing to do.

Better way?
The command for sx under minicom settings just said "sx -vv", but I finally found out elsewhere how to use it. I put the following in a bash script:

Code: Select all

sx -vv $1 < /dev/ttyUSB0 > /dev/ttyUSB0

result:

Code: Select all

$ sendpi kernel.img
Sending kernel.img, 257 blocks: Give your local XMODEM receive command now.
Bytes Sent:  33024   BPS:5547                            

Transfer complete

Now that's pretty convenient!

[dwelch67]

right, I didnt get the key sequence right in my prior post. I use the uart immediately after loading so I stay in the minicom world the whole time other than when minicom launches sz, so I personally let minicom manage the xmodem transfer, and you will see in at least some examples I have a loop that prints stuff to the uart, this is an intentional delay to cover the time when sz is exiting and minicom is getting control back. Perhaps I am not completing the xmodem transfer properly.

If you dont mind I will try to remember to take your command line and add it to my readme...likewise this forum will help folks with the same problem. I have tried and failed in the past to do things with sz without outside help...

David

[gaidal]

I don't mind, would be proud to contribute to your epic readmes!

Do you mean you stay in minicom so you can read data back from the program? I definitely need to check those examples out.

And maybe think of a way to build a USB extension cord with a power switch!

[gaidal]

I have discovered some weird behavior with sx, which might partly explain why people are having problems using it from the command line.

Right after booting Linux, I can't get sx to work unless I use minicom first. It doesn't matter how many times I reconnect my cables and retry, it won't send. Once I've sent once using minicom, it works until I turn my computer off, even if I pull out the ftdi/tty-usb cable and connect again. It's not like I've tried this 100 times yet, but it sure looks like something is going on.

We might want to figure out what this is before telling people that they can use sx in a script with the bootloaders.

[dwelch67]

are you using setserial or whatever the command is to configure the baud rate, etc for the port? Wondering if that is the reason why you need to use minicom, to setup the port...

[gaidal]

Set baud rate, huh...

I have a lot to learn about terminals and (serial) interfaces, never tried these things before.
I am still looking for a better work process, because although I can quickly power cycle the pi with the extension cord in my lap and send a binary with a single command... I don't know how to I would print things back to my terminal, or maybe see what's being sent, or just generally debug programs.
The last few days I've debugged with small tests that set the status LED, and with just 1 bit of feedback it takes pretty long. After maybe 100 tiny changes and reboots just to see if the LED is on or off, I'm eager to find a better process.

For now, this command seems to make sx work without starting minicom:

Code: Select all

stty -F /dev/ttyUSB0 115200