XMODEM not working correctly
Eröffnet am: 2017-10-12 23:00
Letztes Update: 2017-10-12 23:00
| Auswertung: | alpierob | Verantwortlicher: | (Keine) |
|---|---|---|---|
| Priorität: | 5 - Mittel | Meilenstein: | (Keine) |
| Typ: | Fehler | Schweregrad: | 5 - Mittel |
| Komponente: | Tera Term | Status: | Offen |
| Lösung | Keine |
Einzelheiten
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!
Kommentar
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 :-(((