The problem is in fact that TeraTerm is not clear the input buffer BEFORE it sends the first packet. Your uC send some NAK while waiting for filetransfer. The PC takes this in the serial input buffer. If you start now the xmodem file transfer, the very first NAK is read from the input buffer of the PC, then the first packet is send and the uC is sending a ACK into ths PC input buffer. But NOW, the second NAK is read from the input buffer instead of the ACK and is interpreted as NAK for the first packet instead of the ACK which is at the end of the input buffer. Therefore the xmodem is sending the first packet again and maybe overwrites your input buffer. (depending of the implementation of the uC code). So the answers from your uC are ALLWAYS shifted how many NAKs are in the input buffer. I fixed it this Way: I read the first packet byte complete (only the count of bytes), after this i waste ALL bytes within 100ms, so no more bytes are present in the input buffer. Then is send the ACK for the first Packet. It worked. I tried this often to explane in a ticket, but nobudy will fix this :-(((
I have fallen foul of this bug recently also when trying to send a firmware file to an Evertz Xenon video router card. The XMODEM implementation in TeraTerm corrupted the upload and wiped the card's firmware. Luckily in this instance there's a jumper selectable fallback to a hard-coded firmware loader, so I was able to use ExtraPuTTY instead, which worked perfectly.
Steve Roberts -- BBC Archives, London
Is there a later version of Tera Term that has fixed the Xmodem transfer problem? I am wanting to use it to update embedded systems. Also, is there a document that specifies the Xmodem protocol as used in Tera Term?
Thankyou
This bug also bricked a device I was working on, Dell MD1200 SAS controllers to be specific. Extraputty worked fine.
Tera Term
Dear, for a Bootloader to a Microchip MCU I wanted to use XMODEM protocol to transfer the HEX file. I meet some problems when transfering the block 6, 21, and some others. The file HEX is all ASCII, then no control characters inside. After an analysis using a hardware protocol analyser I realized that your software is not clearing the RX buffer when finish transmitting the block, then is listening to itself (to the ECHO) when transmitting the block. As the block number 6 is transmitting a '0x06' as block number, when finish the transmission your software is interpreting that '0x06' as ACK and transmitting immediately after the block 7 without waiting to my answer. Same happens when transmitting block 21. As the block number is 21, your software is interpreting his own transmitted '0x15' as NAK and re-transmitting endlessly the block 21. XMODEM was done to avoid just that, the ECHO that the very old modems have, it should not listen to itself, but open the RX only when finish transmitting the block. I'm using (for simplicity) a half-duplex port, one pin share RX and TX, that's why I selected XMODEM as protocol. I have done my own serial software and it it works, but will be quite nice if you can "correct" your software. Thanks!