This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bug in lsz file transfer?

The time has come that I can't put up with 20% transfer efficiency any more.  I need to figure out why lsz is sending bad packets.  More specifically, hyperterm is reporting "Error in Packet Format" repeatedly.

History: Having been unable to find a file transfer utility from DM6467 to host computer, I found lsz source and got it compiling.  Reference: "This is a Serial Transfer utility for DM6467T (and others) <-> Host Computer (PC tested)" http://e2e.ti.com/support/embedded/linux/f/354/t/103912.aspx#365474 

So, might someone offer me some advice on this?  The link above includes an attachment with the source in it.

Thanks sincerely.

  • See the above link for resolution.  Repeated below...

    ------------------------

    This is hilarious.  The 20% throughput speed was because lsz is default sending continuous status info out stderr, which defaults to the same channel as stdout, which is the channel over which the transfer is happening.  Hyperterm views these interlaced status messages as bad packets, which they are.  Redirecting or eliminating this stderr output fixes the problem.  Throughput is now about 72% at 921,600 baud.  I wish it were closer to 95%, but I'll settle for 72%... for now.

    EXAMPLE ONE, tell lsz to be quiet and not send status to stderr.  This should speed up some as well because the time isn't spent writing to stderr file every packet

    lsz -q filename

    EXAMPLE TWO, redirect stderr to a file.

    lsz filename 2>upload.out

    EXAMPLE THREE, the best of both worlds.  Don't spend time writing status to file every packet, but if an error does arise, save it

    lsz -q filename 2>upload.out

    EXAMPLE FOUR, upload all my desired files.

    lsz -q wildcard*.ext 2>upload.out