XMODEM question

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I only want to support the CRC version of XMODEM, the receiver begins by sending an ASCII "C" instead of NAK, and then switches over to using NAK once underway if there is a failed packet.

 

The question is when *exactly* does this switchover happen?

 

If the very FIRST Packet fails its crc, does it get a NAK?  or does the receiver respond with a "C" until it gets its first good packet?  I ask because if the first packet (or something) was received, but it wasn't good, will NAK confuse the sender into thinking it should do checksum instead of CRC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There's a spec for XYZ that explains all this. By the way I'd highly recommend Ymodem over X because it sends exact byte length (not just N lots of 128/1024).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
There's a spec for XYZ that explains all this

Indeed.

 

https://en.wikipedia.org/wiki/XMODEM - see links at the end

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
The XMODEM/CRC protocol is similar to the XMODEM protocol,
      except that the receiver specifies CRC-16 by sending C (Hex
      43) instead of NAK when requesting the FIRST packet.  A two
      byte CRC is sent in place of the one byte arithmetic checksum.

 

I'm going to take this to mean that ANYTIME it wants the first packet, even after a failure, it is to use the "C".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone have any ideas about this:

 

https://ttssh2.osdn.jp/manual/4/...

 

There is a binary checkbox in teraterm - is there any sort of XMODEM transfer that is non-binary??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
is there any sort of XMODEM transfer that is non-binary??

No. I suspect that's purely for the benefit of Teraterm - how it processes the data before/after XMODEM ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I suspect that's purely for the benefit of Teraterm
Agree. The usual distinction between "text" and "binary" is whether any processing is done on 0x0D's and 0x0A's in the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

clawson wrote:
The usual distinction between "text" and "binary" is whether any processing is done on 0x0D's and 0x0A's in the data.

Agree!

 

eg,

 

EDIT

 

I know that dialogue has nothing to do with file transfers - it's just to illustrate the fact that TeraTerm (and, in fact, terminals in general) does do new-line processing when it thinks (or has been told) that the content is "text".

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Feb 22, 2021 - 10:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you want to use Xmodem?

Ymodem and Zmodem are much more reliable.

 

In the Olden Days with 300 Baud Modems and NO error correction you would often have glitches in Xmodem packets.   Xmodem would send the packet again.

 

However,  with certain bytes the re-send process did not work.   From memory Xmodem-CRC was "better" than the original Xmodem which used a simple CheckSum.    But you could still end up either with a corrupted file or just fail.   Failure was preferable to a corrupt file.

 

When Error Correcting Modems arrived Xmodem just worked.    But Zmodem had also appeared by then.

 

I presume that you are using a noisy radio link.   So errors are inevitable.

 

But if you are simply storing binary data in a Flash chip from a PC via a USB cable it should be "noise free".

CRCs are a good idea.    But mostly for your peace of mind.    I bet that you never get a CRC failure.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't YMODEM just XMODEM-CRC plus the initial "metadata" - no extra error detection or correction?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I presume that you are using a noisy radio link

I didn't get that from the OP ?

 

But, if so, that's really not what X (or Y or Z) modem were designed for.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

david.prentice wrote:
Why do you want to use Xmodem?
Well X is undoubtedly  simpler to implement than Y (which in turn is simpler than Z).

 

But, yeah, X is almost "too simple". Y is a happy balance in the middle.

 

BTW unless doing it as a "learning experience" I don't see much point in reinventing this particular wheel. You can google "Ymodem in C" and hit things like:

 

https://gist.github.com/zonque/0...

 

Of course the only downside of code you fid out on the net is that you don't know the provenance. It could be a work of genius or a pile of steaming poo. I just picked the above at random. The lack of any coherent comments would make me suspect it a bit.

 

I guess the "trick" when using code from the net (like Fleury libraries) is to find some that is highly recommended by many people which is some proof of provenance.

 

BTW just following another google hit I also came across:

 

https://code.aliyun.com/mico/mic...

 

You only need to compare the two (and the existence of rich comments in the latter) to suspect it is more professionally written!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote an X-MODEM sender many many years ago:

 

I see this struct in my code:

typedef struct
	{
	uint8_t StartByte;
	uint8_t PacketNumber;
	uint8_t OnesCompPkt;
	uint8_t Data[128];
	uint8_t CRCHighByte;
	uint8_t CRCLowByte;
	} xmodem_pkt_t;

The CRC is populated using _crc_xmodem_update from <util/crc16.h>

I had an ultra simple state-machine for the Sender

 

  1. 'C' The start/sync character merely zeroed my next packet number
  2. ACK incremented the next packet number. (Obvisouly, with an end of array check)
  3. NAK Just gave up and started the whole session over again

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Here is what I am working on - a hexadecimal control panel Intel 8080 emulator.  The idea is for someone who has never used an "old" computer to be able to experience programming opcodes and stepping them one at a time, similar to some of the microprocessor trainers of the late 70's, but with more debugging faculties.  The user can view and change registers and set breakpoints for example.

 

I've tried to expose as many resources as I can from the ATMEGA1284 which has turned out to be quite decent.  The emulator will have 15K SRAM, 4K internal EEPROM,  96K FLASH mapped into the emulation's addressable area.  (The 96K FLASH is 3 bankable 32K sections at 0x8000-0xFFFF.).

 

There are 3 buttons that deal with all of the memory types in pages (256) and not bytes, so you can copy between any of the memory types, fill them with a value, or crc16 test them.  All have a page number, so you can copy from external EEPROM to SRAM, or SRAM to FLASH, or SRAM TO SRAM, and so on.  One of the page types is 601 (see table below) so you can copy to or from XMODEM to any memory type, or vice versa.  I don't need a filename or exact size to be sent, just the raw data in 256 byte pages (which in this case is two 128 byte XMODEM packets).

 

I might try to do Intel HEX format next at page 801/802 for COM1/COM2 which is really usart0/usart1.

 

I won't have compatibility with any specific trainer or old system, but I am going to get Altair 8K BASIC running on it by modifying its input/output routines.

 

AVR flash map (bytes not words):
  NAME			ADDR		SIZE
  application		0x00000		0x7700 (29.75K)
  configuration		0x07700		0x100 (256B)
  flash bank 0		0x07800		0x8000 (32K)
  flash bank 1		0x0F800		0x8000 (32K)
  flash bank 2		0x17800		0x8000 (32K)
  bootloader		0x1F800		0x800 (2K)

Emulated address map:
  NAME			ADDR		SIZE
  static ram		0x0000		0x3c00 (15K)
  internal eeprom	0x6000		0x1000 (4K)
  flash bank 0		0x8000*		0x8000 (32K)	*the flash bank switched in will be active
  flash bank 1		0x8000*		0x8000 (32K)
  flash bank 2		0x8000*		0x8000 (32K)

Copy Fill Test page map:
  NAME			PAGE		PAGES		GROUP
  static ram		0x00		0x3c (15K)	GROUP_SRAM
  internal eeprom	0x60		0x10 (4K)	GROUP_INTEEP
  flash bank 0		0x80		0x80 (32K)	GROUP_FLASH*	*the flash banks can be treated as contiguous together
  flash bank 1		0x100		0x80 (32K)	GROUP_FLASH*
  flash bank 2		0x180		0x80 (32K)	GROUP_FLASH*
  external eeprom 0	0x200		0x200 (128K)	GROUP_EXTEEP0
  external eeprom 1	0x400		0x200 (128K)	GROUP_EXTEEP1
  com1 xmodem		0x601		n/a		GROUP_COM1
  com2 xmodem		0x602		n/a		GROUP_COM2

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

How about SD/MMC ? (possibly the closest thing to 5.25" / 8" disks that might typically have been used with an 8080/(Z80) based micro like this for program storage)

 

If you have a "disk" you can then look at running CP/M :-)

 

 

(of course you will want a bit of RAM for the TPA with that!)

 

Anyway exactly what has specified:

  com1 xmodem		0x601		n/a		GROUP_COM1
  com2 xmodem		0x602		n/a		GROUP_COM2

should exist?

 

Last Edited: Mon. Feb 22, 2021 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>How about SD/MMC ? (possibly the closest thing to 5.25" / 8" disks that might typically have been used with an 8080/(Z80) based micro like this for program storage)

 

I keep wanting to do some more with SD/MMC, but this device is somewhat a "no filesystem" type device just dealing with memory ranges in pages/blocks.

 

>If you have a "disk" you can then look at running CP/M :-)

 

The idea has been wrestled, but it always comes down to simplicity and sram.  I thought about trying to do a custom CP/M version in flash leaving somewhere near 14K or so TPA, which is not enough already, but it probably is not worth the work.

 

>Anyway exactly what has specified:

>should exist?

 

Just firmware!  If you press the copy button above, it will prompt for the "copy page".  If you specify 601, then xmodem becomes a source so it will invoke xmodem download.  For the destination page then you could select a page for sram, internal eeprom, flash, or external eeprom and download directly to one of those memories.  Going the other direction, if you want to upload the entire 128K contents of an external exprom via xmodem, you would copy from page 0x200, destination page 0x601, number of pages 0x200.  Technically you could specify 601 for the "copy page" and 602 for the "destination page" and the device could be an xmodem router downloading pages from COM1 and uploading them to COM2 at the same time.  Not exactly useful, but I plan to test it just to see if it could work.  The idea behind this is having a single "copy" button that can be used to move memory from any memory to another memory, but in this case a virtual xmodem memory page is available that allows xmodem to be the source or destination or maybe both.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just throwing ideas out there - but as an alternative to Xmodem have you thought about TFTP ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does TFTP require ip/ethernet?  I remember using it on some Cisco routers for firmware a number of years ago.

 

I may still try my luck with intel hex, but the challenge there is that it doesn't have to be in pages.  I am writing the flash in pages, so I'd have to let it fill up a buffer and then write the page, assuming the intel hex had an entire page in order.  it wouldn't matter for sram or internal eeprom if the intel hex was scattered around a bit.