XMODEM not working correctly
Eröffnet am: 2017-10-12 23:00
Letztes Update: 2019-06-18 20: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
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