Fasttrack Supreme App Download - XModem (BAD CHECKSUM)



I am trying to download applications to Fasttrack Supreme using HyperTerminal and XModem protocol.
The Hello_world binary works (maybe because of it’s small size of < 10 KBs), but larger binaries
(Open-AT samples pre-/self- compiled) throw “BAD CHECKSUM” to the terminal.

Anyone else who has experienced something like that?

I had read in this board about DWLWin.exe which seems not to be included on my SDK-CD. I already notified my vendor,
but he has not answered until now. Maybe that could “bridge” my problem, but it would not solve it, because XModem upload
should work anyway.

Thanks for any suggestion.


Note that sending stuff to the modem is usally reffered to as downloading… 8)

You do have hardware flow control enabled, don’t you?

See: viewtopic.php?f=30&t=1737&p=6344&hilit=hardware+flow+control#p6344


Yes, FlowControl is set to “Hardware”.


I’d like to share what I found out.

BAD CHECKSUM was the result of handing over the physical COM-port of my unix system via rdp to my virtual machine.
I do not know if it would work with connecting the device directly to the VM host computer and enabling access for the VM.

So this does not work with app-downloads (but it does with normal communication):

------------(TCP/IP [rdp])------------- : <Virtual Machine (HyperTerminal)>
|(serial link)

After connecting the modem to a “real” host computers serial port the download (XModem) succeeded!
Hope this could help some people in a world where virtualization is getting more and more important.


Is that how you intended your diagram to appear?
You need to use the ‘Code’ tags to preserve the formatting for “ASCII-Art” like that - and check it in the Preview.

Did you determine where the problem(s) lay?

Note that XMODEM does require a clear channel that handles 8-bit binary data fully transparently…

And, as already noted, Wavecom’s XMODEM implementation does require hardware flow control…


I checked the diagram in the preview and yes that is how i tried to communicate with the modem.

1.) the modem was serial linked to my unix system
2.) the remote desktop connection passed “/dev/ttyS0” link to the VM (hosted by another physical host)
3.) hardware flowcontrol was selected and the COM port was opened in the VM
4.) sending AT-commands and receiving answers did work

I never tested passing a com-port via rdp and using hardware flowcontrol, before - but should work.
(my serial tester [between modem and host] determined that all serial channels are used properly)


OK - so I just don’t understand the diagram! :blush:

From your description, it sounds like you have:

<other host>
     | remote desktop connection
 <unix box>
     | RS232 local connection

is that it?