Putty Xmodem File Transfer

Hi All, I have been working on getting a bootloader up and running on the AT91SAM3X8E (Arduino Due) using Atmel Studio. Atmel have provided an example bootloader on their site but it was written for IAR workbench so I have tried to convert it to Atmel Studio 6.2 I am able to upload the bootloader and get it to upload a program I made but a few strange things are happening and I just haven't been able to figure out why. Below is two screen shots. The top screen shot is what the program should look like. If I upload this using SAM-BA in the flash location 0x89000 the bootloader runs it no problem. The bottom screen shot is what gets put into the flash on the chip when I upload using XMODEM.

There seems to be two 0xF0 at the start. The problem is that I don't know why and I can't just say ignore 0xF0 as it is needed in other parts of the program. This is the code that does handles the uploading of the new program. This is what I currently have planned for this in the long run and would like comments if it sounds like a terrible idea. Each of these devices will have an xbee connected to it.

There will be one device that will hold the latest firmware lets call it the server. Each of the other devices will have the bootloader start and poll the server and check if a new version is on it. If so then it will transfer all of the data to the device.

Putty Xmodem Plugin

I was thinking that the whole firmware would be sent and then error checking would be done on the full transfer and not with each packet that was sent. This is because I would like to be able to push out new firmware in a broadcast to every device on the network. This will save a lot of time as there could be upto 200 devices and each of these devices updating its firmware one at a time will take a long time. Am I crazy or is this doable?? Will use MD5 hash as the checksum unless someone can suggest something better? 'XMODEM' was both an early file transfer protocol (packet format approx SOH BLKNUM BLKNUM CKSUM), AND a common name for programs that implemented that protocol (along with, perhaps, simpler, protocol-less 'upload' features. I'll assume: 1) You're referring to the the bootloader described in 'Atmel AT02333: Safe and Secure Bootloader Implementation for SAM3/4' (which does not include ANYTHING about 'xmodem.'

) 2) You're using some program that you're calling 'xmodem' (which one?) 3) this program is transmitting the extra F0s. (I'm not sure why; that isn't a sequence I remember being used in any XMODEM-like protocol.) 4) The 'protocol' described in this app note is pretty awful; they seem to be spending more attention to encryption issue that data transmission integrity.

So I have found my problems but not all are fixed. I was using an Arduino Uno without the ATmega328 chip, this was the reason I was getting 0xF0. Changed it and am now using an FTDI chip thats on an XBEE board. Possibly buffer size was to small, I made it larger just incase.

Extraputty 0.30 2016 04 04

I have had such a crazy week and I don't even know where I got XMODEM from. The uploader that came with the provided example from ATMEL has XON/XOFF and I must have linked the two together. The new problem that I have come up against is that I transfer the file but only the first and last parts get stored into the flash memory.

I will work on that problem and see why it is happening and try and sort it out. Thanks everyone for all your help, I feel yet again like an idiot because it was nothing to do with XMODEM at all. 'XMODEM' was both an early file transfer protocol (packet format approx SOH BLKNUM BLKNUM CKSUM), AND a common name for programs that implemented that protocol (along with, perhaps, simpler, protocol-less 'upload' features. I'll assume: 1) You're referring to the the bootloader described in 'Atmel AT02333: Safe and Secure Bootloader Implementation for SAM3/4' (which does not include ANYTHING about 'xmodem.' ) 2) You're using some program that you're calling 'xmodem' (which one?) 3) this program is transmitting the extra F0s. (I'm not sure why; that isn't a sequence I remember being used in any XMODEM-like protocol.) 4) The 'protocol' described in this app note is pretty awful; they seem to be spending more attention to encryption issue that data transmission integrity.

SolutionYou can use the following set of commands to copy an IOS imageonto a router through either the console or the AUX port: Router1# copy xmodem: slot1:. WARNING.x/ymodem is a slow transfer protocol limited to the current speedsettings of the auxiliary/console ports. The use of the auxilaryport for this download is strongly recommended.During the course of the download no exec input/output will beavailable.-.Proceed?

Xmodem File Transfer Utility

confirm Destination filename ? C3620-ik9s-mz.122-12a.binErase slot1: before copying? confirm Use crc block checksumming? confirm Max Retry Count 10: Perform image validation checks? confirm Xmodem download using crc checksumming with image validationContinue? confirm Ready to receive file.CC bytes copied in 1450.848 secs (961 bytes/sec)Router1#. DiscussionIt can be quite useful to be able to load an IOS image through aserial connection, particularly if you don’t have access to a TFTPserver, or if the router doesn’t have any accessible LAN interfaces.Although this feature is rarely used, Cisco does support xmodem and ymodemfile transfers through a serial connection.We also recommend enabling the CRC checksum feature when you usexmodem to download an IOS imagethrough a serial connection.

This will help ensure the integrity ofthe file transfer.We should stress that this process can be extremely slow. Don’teven attempt to download an IOS image at the default speed of 9,600bps unless you have an entire day to kill. We highly recommendincreasing the speed to the highest value that your terminal emulationpackage will support. We have found that 115,200 bps provides themaximum throughput with the most reliability. The speed command allows you to change thespeed of an asynchronous serial port: Router1# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router1(config)# line aux 0Router1(config-line)# speed 115200Router1(config-line)# endRouter1#In this example, we used Hyperterminal because it is included withthe Windows operating system.

However, almost any terminal emulationprogram that supports xmodem orymodem protocols will work. Infact, we have found significant differences in download times betweenthe various emulation packages, and Hyperterminal tends to be one ofthe slowest. Other packages such as ProComm tend to be somewhatfaster. But they all work.Even after we increased the speed of the Aux port to 115,200bps, the file transfer took nearly 25 minutes to complete.

Bycomparison, loading the same IOS version via TFTP through an Ethernetconnection took less than four minutes. So, in general, we don’trecommend using this method unless you can’t use TFTP for somereason.The first step, once you have a copy of the IOS image on yourcomputer, is to connect to the router’s AUX port. Set the line speedto 115,200 bps on both the console port and the terminal emulator, andissue the copy command.

Therouter will prompt you to begin the file transfer with the text “Readyto receive file.”At this point, you should begin your file transfer protocol. Ifyou are using Hyperterminal, select the “Transfer” drop-down menu, andthen click on “Send-file.” It will prompt you for the file name andlocation, and protocol type. Enter the name of the IOS image, and thenselect “Xmodem” to start the file transfer.During the file transfer, the connection is busy transferringthe file, so the router can’t display any messages. This is normal.However, most terminal emulator programs provide a status window tolet you keep track of the file transfer.When the transfer is complete, the terminal emulator will dropout of the file transfer mode and the router will put up its normalprompt again. At this point, we highly recommend checking the new IOSimage to make sure that it copied successfully. You can verify thefile size as follows: Router1# show slot1:PCMCIA Slot1 flash directory:File Length Name/status1 11922512 c3620-ik9s-mz.122-12a.bin11922576 bytes used, 4592496 available, 16515072 total16384K bytes of processor board PCMCIA Slot1 flash (Read/Write)In this case, we loaded the image into the PCMCIA device in slot1.

If you put the image somewhere else, such as the internal flashmemory, you would use the command showflash: instead.If the file size is correct, check the image’s checksum by usingthe verify command: Router1# verify slot1:c3620-ik9s-mz.122-12a.binVerified slot1:c3620-ik9s-mz.122-12a.binRouter1#With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,learning paths, books, interactive tutorials, and more.