Problem using Xmodem ROM services on AT91

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi everyone,

Im using a custom board, with an AT91rm9200. Im am trying to load some
code onto the microcontroller using the xmodem protocol, but things
dont seem to be going right. I am using the Debug port to transmit data
serially to and from Hyperterminal in windows.

I am using the xmodem ROM services on the 9200. I had borrowed code
from the Application example on ATmel`s site
(AT91RM9200-BasicROM_Services-ARM1_2-2_0), so it wud seem that the code
is okay.

This is what happens: i switch on the board, i see "ccccc" on
Hyperterminal sent by the default boot program on the at91rm9200, so i
load my program. then, when the program is executed, i see "cccc"
again, indicating that the xmodem service was re-initialised correctly.

But after this when i try to send my code, Hyperterminal flashes a
"Retry Request Received" and then stops, saying : "Error Limit
Exceeded". It seems that the code stops at this point:

xmodemPipe.Read(&xmodemPipe, (char *)ADDRESS, MAXSIZE,
AT91F_XmodemProtocol, 0);

I have tried different values of ADDRESS and MAXSIZE, but to no
avail..what could be wrong?? i can post the full code here, if it wud
help detect the problem..

Thanx,
Mayank


Re: Problem using Xmodem ROM services on AT91
Quoted text here. Click to load it

The problem may be that you are using Windows.  Xmodem protocol
depends highly on instant response to various signals, and Windoze
and lack of real serial ports (often simulated on USB) foul that
timing.  You would be better off with the Zmodem protocol.

The sort of thing that happens is the sender ends a transmission,
and turns the i/o around in order to hear an ACK.  While it is
doing that the receiver sends an ACK, which is missed because the
line didn't turn on time.  So the sender concludes there was an
error, and resends.  It all happens again, until "Error Limit
Exceeded".

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem using Xmodem ROM services on AT91
Quoted text here. Click to load it

This simply isn't true. XMODEM may be lame, but it certainly doesn't
require, or expect, "instant response".

Quoted text here. Click to load it


Perhaps on a bit-banged software UART that might occur, but not in
a hardware UART operating full duplex.  Unless the sender code is
written so badly that it turns off the receiver, or otherwise ignores
characters coming in.

--Gene


Re: Problem using Xmodem ROM services on AT91
Quoted text here. Click to load it

Exactly.  I didn't say that was occuring, just that it might.  I
had this same problem with micro/mainframe communications
twenty-five years ago, and the cure was a delay at the micro end
between receiving the last byte and returning the ACK.  IIRC that
had to be around 10 millisec, which played hob with the throughput
rate.  That's why it is better to use a windowing protocol such as
Zmodem.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem using Xmodem ROM services on AT91
Quoted text here. Click to load it

FWIW, the standard timeout with XMODEM is 10s. IOW while a short delay might
hurt throughput, it's unlikely to be causing aborts.

Steve
http://www.fivetrees.com



Re: Problem using Xmodem ROM services on AT91
Quoted text here. Click to load it

That's not the problem.  The receiver gets the last byte of a block
and responds with ACK immediately.  It now waits for a new block.

Meanwhile the sender, after sending the last block, does sender
things (such as unblocking a process after i/o) and then gets
around to arming the i/o system to hear the ACK.  Its been and
gone, so it waits with a notable lack of success.

With everybody waiting, sooner or later something will time out.
If the receiver times out first it sents NAK, signalling error, and
the transmitter resends.  If the transmitter times out first it
awaits a NAK (Xmodem is receiver driven) and resends.  In all cases
there is an error and it never heals.  This is 25 year old
analysis, so there may be bits dripped in my memory.

Nowadays the reason for missing the ACK may be different in detail,
but I suspect such things as USB substitutes for serial ports.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem using Xmodem ROM services on AT91

Quoted text here. Click to load it
...


I think You want o get hold of the Flash ISP application "loader.bin" from
you local Atmel contact.
This shows  how to download code over Xmodem and flash the result.

--
Best Regards
Ulf at atmel dot com
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem using Xmodem ROM services on AT91
Hi,Ulf

Quoted text here. Click to load it
from

I got an example from the AT91-CDROM that shows how to overload this
Read function..maybe its the same one ure talking about. Since the Read
function is overloaded, i could actually see what it was trying to do,
and pull an arm here and a leg there. Its working, now i can actually
send the downloaded data straight to a 2-wire eeprom.

But i still havent been able to get the default Read function to
execute properly.

Regards,
Mayank


Site Timeline