From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jorg Rapka To: "Gary Thomas" Cc: Subject: AW: [ECOS] redboot Date: Wed, 08 Nov 2000 01:06:00 -0000 Message-id: References: X-SW-Source: 2000-11/msg00100.html Dear Gary Sorry for this: "it did not work so well." Here are a lot of information! My platform is a Motorola 68331. What problems did encounter: - I'm connected by a serial line with a terminal (COM7.1 from tlgmicro). I start the download process with command "load". Now the character 'C' will be send by redboot to start the transmission. - I start with XMODEM CRC (use 128 byte per data block). This protocol did not send the file name as first data block. So I get into trouble in function "xyzModem_stream_open". For the YMODEM protocol you ignore this file name data block: // Note: yModem file name data blocks quietly discarded xyz.next_blk = 1; xyz.len = 0; I replaced the above code by this one: if (mode == xyzModem_xmodem) { xyz.next_blk = 2; } else if (mode == xyzModem_ymodem) { // Note: yModem file name data blocks quietly discarded xyz.next_blk = 1; xyz.len = 0; } XMODEM sends the first data block with block number 1. So the next block is #2. - As I understood you do the following: The function "xyzModem_get_hdr" receives a data block. If this data block is correct, it will be acknowledged by sending an ACK. The function "do_load" of module "load.c" receives 512 bytes into a buffer (first the data received by function "xyzModem_stream_open" are used; if more data requested the function "xyzModem_stream_read" will be called). First I tried to download SREC files: (1) one with approx. 40 characters SREC -> so only one data block (128 bytes) will be send (2) another with approx. 160 characters SREC -> so two data blocks (each 128 bytes) will be send What happens in case (1): The function function "xyzModem_stream_open" receives the only one data block and acknowledge it. The sender then will send the EOT data block. The function "do_load" want to fill its 512 bytes buffer. The first 128 bytes are get from the data received by function "xyzModem_stream_open" above. The other 128 bytes are get by calling the function "xyzModem_stream_read" (EOT data block, which will also be acknowledged). So for the sender the protocol is OK. What happens in case (1): The function function "xyzModem_stream_open" receives the first data block and acknowledge it. The sender then will send the second data block. The function "do_load" want to fill its 512 bytes buffer. The first 128 bytes (first data block) are get from the data received by function "xyzModem_stream_open" above. The other 128 bytes (second data block) are get by calling the function "xyzModem_stream_read" (which will also be acknowledged). Then the sender will send its EOT data block. The function "load_srec_image" will process the S-Records and stop the load command, if it get an address termination record. In this case the EOT data block is not yet acknowledged and the sender cause a protocol failure. Solution: If the function "load_srec_image" get an address termination record it must receive data until the EOT data block is acknowledged. - There is another problem with the YMODEM protocol. This protocol will first send a file name data block (this will be handled correctly). But before the EOT data block another empty file name data block will be transmitted, which will not be handled and cause a protocol error at the sender side. NOTE: What kind of download did you test - only RAW or also SREC? What terminal application did you use? Thanks in advance for discussion. Best regards, Joerg -----Ursprungliche Nachricht----- Von: gary@ares.chez-thomas.org [ mailto:gary@ares.chez-thomas.org]Im Auftrag von Gary Thomas Gesendet: Dienstag, 7. November 2000 17:11 An: Jorg Rapka Cc: ecos-discuss@sourceware.cygnus.com Betreff: RE: [ECOS] redboot On 07-Nov-2000 Jvrg Rapka wrote: > Dear ecos developer > > I'm very interested in the redboot of ecos. > I have downloaded the latest version from CVS. > In the sources I found the information, that > not only download by TFTP but also xyzmodem > will be supported (the documentation only > references TFTP). I compiled the sources > and tried download by xyzmodem, but it did > not work so well. > What is the status of this implementation? > What was your terminal application and protocol > used during development tests? Currently only Ymodem (or Xmodem with CRC) is implemented. What platform did you try this on? What problems did you encounter? It's pretty hard to help much if all you give us is "it did not work so well."