Download progress dialogue - 101% !!


#1

When download a .dwl file from M2MStudio 1.1.1, my download finishes when it reaches 280/279 blocks!! :open_mouth:


#2

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 :smiling_imp:


#3

I’ve not seen any errors - just noticed that it seems to count 1 more block than “required”!


#4

yeah, regularly uploads more bytes when the reported size,
no error is given, and is seems to be consistently at 1-2% overrun.


#5

Is it actually sending extra bytes on the wire, or is it just mis-reporting it?


#6

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.


#7

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!


#8

awneil, do me a favor, i’m curious: how fast Xmodem-1K with hardware flow on large project? For comparison.


#9

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.


#10

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) :question:


#11

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.


#12

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.


#13

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).


#14

I find that it does - even with a “normal” serial cable @ 115200; it’s not quite so noticeable, but it is still there.


#15

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!


#16

Seems to have been fixed by R73a: https://forum.sierrawireless.com/t/serial-port-data-transmission/4435/14