When download a .dwl file from M2MStudio 1.1.1, my download finishes when it reaches 280/279 blocks!! 
Yeah, happens very often and 100% when working with Q24, it reaches over 100%, then gives an error, but the file is actually loaded fine. Adds to the fun in programming 
Iāve not seen any errors - just noticed that it seems to count 1 more block than ārequiredā!
yeah, regularly uploads more bytes when the reported size,
no error is given, and is seems to be consistently at 1-2% overrun.
Is it actually sending extra bytes on the wire, or is it just mis-reporting it?
Dont know why, maybe because of no hardware flow control (Q24 with half-duplex RS-485), but i never especially succeed software download with m2m studio. Or even recommended Xmodem-1K at all. Too slow, periodic freezing, sometimes abort with strange error messagesā¦
The best and fastest solution i found - Xmodem-CheckSum at 115200 bps without any flow control. Works for me and works fine.
Wavecomās 1K-XMODEM implementation for the software download certainly does require hardware flow control:
forum.sierrawireless.com/viewtop ā¦ ow+control
See my post right at the end of this thread:
[forum.sierrawireless.com/t/download-the-dwl-application-with-only-rx-and-tx-ua/251/13)
It seems to me that the actual writing to the deviceās flash is not synchronised with the XMODEM blocks; ie, the device can stop to write to the flash in the middle of receiving an XMODEM block. At this point, it asserts flow control while itās doing the flash write, and the sender must observe this - otherwise the data gets lost or corrupted or whatever.
This is supported by watching the XMODEM progress - you can see it pause at around each 50th block.
With 128-byte XMODEM, I guess you can just āget away with itā - but not with 1K blocks!
awneil, do me a favor, iām curious: how fast Xmodem-1K with hardware flow on large project? For comparison.
Itās just a known issue about progress reporting (planned to be fixed in TM refactoring, the same for the pause every 50-60 blocksā¦). Donāt worry, no extra bytes are sent.
E?? I thought that was actually due to the module - as this is the same irrespective of what XMODEM implementation you use (Hypoterminal, custom implementation, etc) 
It is actually mainly a specific Studio issue. The pause typically occurs when the protocol falls in timeout while a flash memory sector is erased. Maybe it can occur from times to times with other tools like HyperTerminal, but clearly less often than with the Studio.
Yes, that is my experience.
No, that is not my experience at all!
If the module stalls the transfer because itās doing a flash sector erase (or whatever), then that will be the same irrespective of what is on the āsendingā end.
The sending end should accurately report progress - so, if the module stalls the transfer, that should be visible in āsenderāsā progress reporting.
Iām using a USB-to-Serial adaptor that has LEDs which flash as data is sent - the pause is clearly visible on these when the āstallā occurs.
Obviously, we wonāt break that.
I guess this is why you are experiencing the pause, since you use a fast download rate.
I was just meaning that with the studio, we are experiencing the pause even with a simple serial cable at 115200 bauds. In the same use case, the download doesnāt pause with HyperTerminal, so we clearly have an issue with that (which is known to be due to downloading through Selima, one again).
I find that it does - even with a ānormalā serial cable @ 115200; itās not quite so noticeable, but it is still there.
Iāve just tried this with Hypoterminal downloading to a Fastrack USB port (ie, not USB-to-serial).
This is very much faster than even USB-to-serial at 921600 baud, but the pauses are still there!
Seems to have been fixed by R73a: Serial port data transmission - #14 by awneil