Hi damorin,
Would you please retrieve the YMODEM log to investigate your problem? Please turn on the YmodemLog entry in the teraterm.ini file. So, Tera Term will log the YMODEM data to the YMODEM.LOG file.
See attached file.
The download speed was 115200 bits/sec, 8n1.
Thank you for your attached file. I have checked the file. It seems that the u-boot does not send the ACK(06h) to the Tera Term. First, Tera Term received the 'C'(43h) and sent the first block. Next, Tera Term received not ACK but 'C' character.
I checked the source code of u-boot.
http://git.denx.de/?p=u-boot.git;a=blob;f=common/xyzModem.c;h=7a46805e13363495103426e057e2d106545b7e0d;hb=HEAD
It seems to be able to output debug string.
If possible, could you show debug output of ymodem transfer, when TeraTerm and HyperTerminal?
Or the log file of PortMon(http://technet.microsoft.com/en-us/sysinternals/bb896644) might useful to check the difference between TeraTerm and HyperTerminal.
To yutakapon
u-boot のソースで、u-boot 側の動作が TeraTerm の動作とマッチしないところはありますか？
Hi damorin,
I found a bug regarding sending block1 is timing, and then I have fixed the bug in the following archive:
http://ttssh2.sourceforge.jp/snapshot/snapshot-20110321.zip
Would you please evaluate the archive?
TO: Maya-san, u-bootのソースコードを参照し、それがヒントとなったようです。どうもありがとうございます。 これで対u-bootで貫通してくれればよいのですが。
Hi yutakapon,
I did 15 YMODEM "send" and no problem at all.
Looking like the bug is fixed.
Thanks
Hi damorin,
Thank you for your quick response. I close this ticket.
This bug is still occurring in latest trunk of TeraTerm on Windows XP SP3, but not on Windows 7 / Vista.
Is there any way to make the snapshot available for re-download so the code fix can be reviewed and redone?
Reply To None
This bug is still occurring in latest trunk of TeraTerm on Windows XP SP3, but not on Windows 7 / Vista. Is there any way to make the snapshot available for re-download so the code fix can be reviewed and redone?
Hi,
a few technicians complained about that but it's difficult to reproduce with the latest release.
I will give it a try with the latest snapshot.
Hi everyone,
If Tera Term has your problem regarding the YMODEM transfering, I will fix the problem. Plase send the YMODEM log if your problem reproduce.
Thanks.
I just added 2 attached YMODEM logs that show the failed WinXP and succeeded Win7 YMODEM transfer with uboot.
Unfortunately, these logs aren't conclusive and look clean.
When we pull logs from the uboot device, we find an extra null character at the end of the 1024 packet at hex 0x400 in the packet.
This doesn't occur with 128 byte transfers. It doesn't occur with 1K YMODEM transfers on Windows 7 using TeraTerm.
Is there something in the SetupComm or other Windows API calls to initialize the COM port which causes a null pad, then eventually leads to a checksum failure?
I will attach a screen shot of our Win7 / XP remote logs as well.
Thanks for any help, --MightyBatgar
It turns out that there was an XP hot fix that started to insert zero length packets into the USB stream if the bytes being transferred was an even multiple of 64 for the usbser.sys driver. http://support.microsoft.com/kb/943198
The default is to NOT insert zero length packets into the USB stream for XP and I think every other Windows OS (including 7 and Vista).
To fix, all I had to do was change the max packet size that TeraTerm sends from 1024 to 1023.
Tera Term
Hi,
sending a file with Y-MODEM is failing quite often when the target is u-boot (2010-12 version) but it is working all the time with HyperTerminal (to my great dismay).
With a serial port monitor, I noticed that TeraTerm is not waiting for the first 'C' to start sending the first block. It is looking like its not flushing its receive buffer before starting.