Xmodem terminating/failing

[RCrowder]

To save you from reading the entire post ;)

Has anyone had issues with xmodem (in uMon) returning back to the
uMon prompt after printing/echoing only one 'C'?


When I came home the other night to continue SD driver development,
this started happening :( I've been trying for the last few nights to
work out why..

Before this started happening I was happy using the Silabs drivers
(from last summer) along with a Olimex JTAG USB dongle, to upload and
test code on the VCMX212 and VC21BR1. Even with a custom built uMon
(version 1.15). Then all of a sudden 'xmodem -dy' starts echoing only
one 'C' character then returns to the uMon prompt. 'xmodem -vdy'
returns 'Cverification passed'.

I first tried updating the Silabs drivers to the latest version 5.2.2,
no joy (Hyperterminal still connects, and uMon commands work fine).
Downgraded those drivers to the older version 4.38 from VC wiki (the
zip file link). Same thing, Hyperterminal connects, uMon works fine,
xmodem doesn't.

I had uMon custom built with the SD driver. So was able to copy the
boot.bin for v1.8.1 from the SD card and re-flash uMon. Same thing,
uMon is fine, xmodem doesn't work :(

Thankfully my hair is quite long at the moment, so will take a few
nights to tear it all out ;)

Any ideas?

[Dan Foisy]

Richard,

Is it possible your filesystem is full? The file erase command in umon
is rather primitive IIRC (I believe this is for performance reasons) -
the file is marked erased but the space is not actually freed. Note
that even if you load a file with the same name as an existing file, the
old file old is not overwritten in FLASH but simply marked erased. You
may have to defrag the flash - I believe the command is tfs clean

Dan

--
Daniel Foisy
Virtual Cogs Embedded Systems Inc.
Unit 4, 5694 Highway 7 East, Suite 311
Markham, Ontario, Canada L3P 1B4
www.virtualcogs.com
416-238-2231

"Your future is modular"

[RCrowder]

Thanks for the quick reply Dan.

I did try a qclean and clean on tfs. No joy with either.

I've setup uMon's run-time trace (Mtrace). And can see the following
coming from the uMon xmodem.c code;

uMon> mtrace cfg 0xc0210000 0x1000
uMon> mtrace on
uMon> xmodem -dy
CuMon> mtrace dump
<0001> Xdown
<0002> Got response
<0003> <0d>
<0004> !

So for some reason the UART is receiving a 0x0D byte, which is
breaking out of the while loop in Xdown function :(

I know this issue is in 1.8 and 1.15 of uMon builds. So I'll JTAG load
and trace through a debug build of uMon another night and dig further.

As a further test I setup a Booter script to recreate my normal uMon
commands. Funnily enough this works :S Curious to work out why
Hyperterminal isn't. I've tried different options in Hyperterminal to
try and fix this, but Xdown always gets an invalid char sent to it.
Something to work out this weekend. In the mean time I can use Booter
to replace Hyperterminal, or linux to transfer via SD card :)