Hi,

I am doing an application about running Linux on an ARM development kit. The bootloader is vivi while the CPU is SAMSUNG SBC2440.

I can "talk" to the board in minicom through RS-232 port.

But when I wanna transfer something through xmodem/ymodem/zmodem, I can't do it in minicom. For example, if I wanna download the kernel into the NAND flash in "load flash kernel x" through xmodem protocol.

How shall I do if I wanna transfer a program in xmodem/ymodem/zmodem protocol?

In minicom, control-A,s will bring up the send dialog. You have a choice of zmodem, ymodem, xmodem, kermit and ascii.

but I found an error while I tried upload via xmodem

+-----------[xmodem upload - Press CTRL-C to quit]------------+
|Retry 0: NAK on sector |
|Retry 0: NAK on sector |
|Retry 0: Retry Count Exceeded |
| |
|Transfer incomplete |
| |
| READY: press any key to continue... |
+-------------------------------------------------------------+

I don't know whether there is any place I need to configure.

It looks like the system that you are trying to upload to does not have automatic transfer detection. You will need to manually start the xmodem receive process on the system before you initiate the xmodem send on minicom.

If it still doesn't work, then the implementations may be incompatible for some reason. In that case, try a y or zmodem transfer instead, as these are both faster and more flexible.

but it works if I use the HyperTerminal on Windows.
On windows, I type the same command to initialize the xmodem transfer procedure and select transfer->Send File to activate the Send File dialog. With this dialog, select the name of the file to send, choose the Xmodem protocol, and then Send.

Thirty year old quick and dirty protocols have their quirks. I remember many problems and incompatibilities with xmodem. The ymodem and zmodem protocols were developed specifically because of the poor performance and error prone nature of xmodem. Perhaps you should consider updating to a 21 year old robust protocol, like zmodem?

I finally solved this problem by reading a SAMSUNG documentation. I need to set the xmodem initial timeout a little longer, i. e. 10 seconds. The original timeout was too short that it can't wait for the file to transfer since I took too long time to select the file to be transferred.

It says:
If ‘transfer incomplete’ message is appeared while writing images, the reason is that the timeout of xmodem_initial is too short. In this case, you can solve the problem by increasing the timeout of xmodem_initial. First check the value of ‘xmodem_initial_timeout’ parameter. if it is too short,extend timeout properly.

vivi> param show
vivi> param set xmodem_initial_timeout 1000000 : “1000000” means 1 second because a unit is
microsecond.
vivi> param save

So I did as follows:

FriendlyARM>param show
Number of parameters: 9
name : hex integer
-------------------------------------------------------------
mach_type : 0000030e 782
media_type : 00000003 3
boot_mem_base : 30000000 805306368
baudrate : 0001c200 115200
xmodem : 00000001 1
xmodem_one_nak : 00000000 0
xmodem_initial_timeout : 000493e0 300000
xmodem_timeout : 000f4240 1000000
boot_delay : 01000000 16777216
Linux command line: noinitrd root=/dev/mtdblock2 init=/linuxrc console=ttySAC0
FriendlyARM> param set xmodem_initial_timeout 100000000
Change 'xmodem_initial_timeout' value. 0x000493e0(300000) to 0x05f5e100(1000000)
FriendlyARM> param save
Found block size = 0x0000c000
Erasing... ... done
Writing... ... done
Written 49152 bytes
Saved vivi private data
FriendlyARM> load flash kernel x
Ready for downloading using xmodem...
Waiting...
ize = 1469952 bytes
Found block size = 0x00168000
Erasing... ... done
Writing... ... done
Written 1469952 bytes
Erase TOC of Wince ..., OK!

How to set xmodem_initial_timeout .