2

I'm trying to upload a firmware file over serial connection to a device that requires YMODEM protocol, from a raspberry pi. After a lot of digging, I keep finding that the sz --ymodem [file] command is the tool to do this. I've already managed to just communicate with the device using this example, but I'm having no luck with sz.

I've read through the sz documentation and it leaves me with a question. How do I determine if it is sending to the device? It is plugged in via USB and has port /dev/ttyACM0. Other examples talk about sending from a remote host to a local host via sz by default, but that's as deep as any explanation goes.

The device has a command which tells it to anticipate a file transfer; I believe this takes the place of rz, but the device documentation says it "Prepares the device for YMODEM transfer via HyperTerminal." I've sent it the files via HyperTerminal and a proprietary program successfully, but I need to be able to do it on linux command line.

I'm sure this is a case of inexperience and I'm missing something obvious, but how can I fully execute this file transfer from start to finish / what am I doing wrong?

Community
  • 1
Jack Mason
  • 21

2 Answers2

1

rz and sz date back to the days when people used to dial into modems attached to larger computer systems and login. To send files back, one of several protocols could be used, kermit, xmodem, ymodem and zmodem.

The channel that the files were sent over were the actual login session. So one would start the transfer program on the host, and it would start its protocol handshaking. Then on the terminal program, you'd activate the transfer protocol option.

The hope was that the terminal program and the host computer would establish their place in the protocol and transfer the file.

Zmodem actually defined a flag sequence, so that when the host started a transfer, terminal programs that supported the automatic start would begin the transfer.

TELIX was a popular terminal program that supported this.

Hyperterm used to support several transfer protocols on the PC. If you were connected to the Pi via a serial port, that may be what you are looking for.

What you need to do is think about yourself as being on the raspberry pi, and running a terminal program on the Pi itself to talk to this serial port.

In my experience, the better serial terminal program to run on Linux is minicom, which does support ymodem.

apt-get install minicom

Run minicom and set up the right /dev/ttySxxx ( apparently /dev/ttyACM0)

sudo minicom -s

and follow the menus

Once you are connected, and are ready to ymodem the file. type control-A, the "S", and use the menu selections to pick ymodem and the file to send

It's been a while, but give that a try

infixed
  • 887
  • Trying to use putty, now getting this error: (putty:732) Gtk-WARNING **: cannot open display: – Jack Mason Mar 30 '16 at 19:06
  • I don't think putty supports in-band file transfer protocols. That's a feature that was added by people forking the project. The GTK warning probably means you are not using X-windows right to run putty – infixed Mar 30 '16 at 19:23
  • Let me verify something here. You're not really sending data back to your main PC, from the pi, because you'd just use scp if that was the case. The device you are trying to send to is attached to a serial port off the Pi. Forget about sending the ymodem over ssh – infixed Mar 30 '16 at 19:31
  • Changed answer to use minicom – infixed Mar 30 '16 at 19:45
  • Have been trying minicom as well. After establishing the right port settings, it says the port is "offline". Sending through the ymodem upload option of minicom then, does one attempt and shows Retry 0: Timeout on pathname – Jack Mason Mar 30 '16 at 19:47
  • Again, I'm rusty, but there should be a stty command to ignore the Carrier Detect signal. Not sure if you can do it inside minicom, or if you have to stty clocal > /dev/ttyACM0. turn off all flow control – infixed Mar 30 '16 at 19:52
  • Are you supposed to get a serial monitor type prompt from target board? That would be typical of serial based systems instead of blindly blasting YMODEM at it. Hit the enter key a few times inside minicom – infixed Mar 30 '16 at 19:58
  • Yes, sending it AT$FWDL command is supposed to prepare it to receive the file. I tried this on HyperTerminal and it worked. – Jack Mason Mar 30 '16 at 20:00
  • if its a typical AT command set copied from the way Hayes modems used to work, then AT followed by a enter should say OK. Does that work? That's typical for inside smartphones these days – infixed Mar 30 '16 at 20:02
  • Try entering a AT&K0 command on minicom to turn off flow control on the device side. When you were using hyperterm to a real serial port, you may have had RTS nad CTS lines, and now you're on a 3 wire connection. By the way, are you sure you don't need a null modem type serial cable on this port? – infixed Mar 30 '16 at 20:05
  • No, it replied to AT with $ERROR=102 (its standard error message for incorrect command arguments) once, then stopped responding to it altogether. It is replying correctly to all the other AT commands it is supposed to receive. For clarification, it is a telematics device with GPS and mobile antenna, like a smartphone. – Jack Mason Mar 30 '16 at 20:06
  • If you have a manual, see if there is a command to turn off flow control in the device – infixed Mar 30 '16 at 20:08
  • The manual doesn't provide any options for flow control, but it does indicate that the device driver is only compatible with Windows. This may be a futile endeavor. – Jack Mason Mar 30 '16 at 20:13
  • When you enter AT$DWDL (then enter key) are you seeing the C characters that YMODEM is supposed to be handshaking with? like CCCCC if you wait a while. That indicates the device side is ready for the Ymodem. I'm looking at a random manual at http://fccid.io/pdf.php?id=2010408 – infixed Mar 30 '16 at 20:16
  • Yes I see these, and have tried sz --ymodem filename and minicom ymodem send while this is happening. Both show timeouts after one try. – Jack Mason Mar 30 '16 at 20:19
  • Can you set the baud rate lower. The AT should let you establish a speed. Maybe one side is too fast. Try something slower like 19.2K. That manual is using 57600. make sure you are using 8 bits no parity too. I need to go. Sorry – infixed Mar 30 '16 at 20:21
  • I've been using 9.6k so far, as per the device standard (this is actually the same manufacturer as the pdf you mentioned, but model AX7) – Jack Mason Mar 30 '16 at 20:24
  • I need to go. Good luck. I'll try to come back if I think of anything – infixed Mar 30 '16 at 20:25
  • I know it's kind of late now, but sometimes embedded devices can have less than ideal timebases, so baud rates can be off a bit. If you set your UART to use two stop bits instead of one inside minicom, your data will go out 10% slower which can help some devices resync the start of each character. Because there is an extra bit of idle time in between characters – infixed Apr 02 '16 at 16:23
0

I think if you do sudo minicom -s it will take you to the setup menu. Make sure you set your port, if it's like a FTDI rs232, rs422 usb to serial cable, to /dev/ttyUSB. It won't even open if it can't find the adapter. Also to send the file you need to send it on one computer, and select receive pretty quickly on the other.....try using FTDI UART terminal for Android. It a little easier and has shortcut buttons.

schaiba
  • 7,631
Jeremy Pittman
  • 1