I think I know what the problem is.
Many receivers (and my device in particular) send "C" periodically (every second in my case). Teraterm stops getting data from com port into internal buffer when the user goes to the menu, CommReceive() is not called anymore. However before this happens, one "C" caracter is read into the input buffer and not consumed (not echoed into terminal). I don't know how exactly this happens. The rest of "C" characters is accumulated in COM port buffer while user selects file.
When transmission starts, input buffer is not flushed. Now if we check the file teraterm/ttpfile/xmodem.c, function XSendPacket(), we can see that this "C" character from internal buffer will trigger transmission of first packet. XSendPacket() also tries to consume all extra characters from internal buffer, but as I said before, there was only one there. After that CommReceive() function is finally called, and all "C" caracters accumulated in COM port buffer are read into internal rx buffer. So when XSendPacket() is called for the second time, it finds another "C" character which triggers packet re-send. The rest of "C" characters in internal buffer is flushed.
1. Flush input buffer when XModem starts
2. Consume all data from input buffer leaving only the last character, before doing the rest of XSendPacket()
3. ignore all "C" characters after the first packet was sent
4. Call CommReceive() at some point before calling XSendPacket() for the first time.
5. something else..
I've chosen variant 3 because it was easiest for me. But I don't think this is the best solution, because other protocols could also be affected in similar way. Variant 4 looks better, but I'm not familiar with the code to chose the best place to call CommReceive().
Here is my solution:
This works perfectly for me.