Problem using Xmodem ROM services on AT91

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

Mayank Kaushik wrote:
> 
> 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..

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 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

In article <41FBAB9C.25865C1C@yahoo.com>, cbfalconer@yahoo.com says...
> Mayank Kaushik wrote:
> > 
> > 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..
> 
> 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.

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

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

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

"Gene S. Berkowitz" wrote:
> cbfalconer@yahoo.com says...
>> Mayank Kaushik wrote:
>>>
>>> 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..
>>
>> 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.
> 
> This simply isn't true. XMODEM may be lame, but it certainly doesn't
> require, or expect, "instant response".
> 
>> 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".
> 
> 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.

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 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:41FCC56F.CFAD2753@yahoo.com...
>
> 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.

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

Steve at fivetrees wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> >
> > 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.
> 
> FWIW, the standard timeout with XMODEM is 10s. IOW while a short
> delay might hurt throughput, it's unlikely to be causing aborts.

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 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

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


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
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Hi,Ulf

Ulf Samuelsson wrote:
> 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.

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