confirming integrety of file after ftp transfer..

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

I wrote up ftp transfer over tcp/ip on UC3A...I currently just dump the new firmware file over ftp which the UC3A installs after running from bootloader.

I am wondering what methods I could place to test the firmware file to make sure its a valid firmware file and is not corrupted after ftp transfer...

I was thinking may be use srec to append to the file a MD5 checksum at the end of the bin? And then do an ftp transfer? Then once the transfer is complete the UC3A does a MD5 again and matches the end of file (last 8 bytes) signature...

What do you guys think?

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

sounds like a plan

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

That is a good approach. You could also use RSYNC to ensure the file never gets corrupted to begin with.

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

hhm... hada look at rsync...its not ftp...so not good.

I am reading up on srec and md5 stuff...
Another question I have is how does the device know that a valid atmel firmware has been received? Do Atmel .bin files have some sort of avr signatures? Or perhaps I need to add that using srec_cat as well...

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

Hey,

Check App Note AVR32758, you can find the pdf and the source files here:

http://www.atmel.com/devices/AT3...

Among other things, they use srec_cat to add a signature at the beginning and a CRC32 at the end of the firmware. I think that is more than enough to check the integrity of the file.

Daniel Campora http://www.wipy.io

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

BTW MD5 sounds like over-kill. I'd have thought CRC32 (which is what srec_cat does anyway) would be quite sufficient. MD5 in code is actually quite considerable - maybe 10KB..20KB?

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

danicampora wrote:
Hey,

Check App Note AVR32758, you can find the pdf and the source files here:

http://www.atmel.com/devices/AT3...

Among other things, they use srec_cat to add a signature at the beginning and a CRC32 at the end of the firmware. I think that is more than enough to check the integrity of the file.

ermm lol thats what I used to crop and make my firmware file... I didnt see any signature being added in that link or a CRC32 be appending...

unfortunately when I am trying to append at the begining a text file data, namely a header signature to the firmware file, its giving me grief...

I get the following error:

srec_cat: flash_header: 1: warning: ignoring garbase lines
srec_cat: flash_header: 2: file contains no data

the following is what I had in my .cmd batch file

srec_cat ^
  ./flash_header -text ^  
  ../RDL/RDL/Debug/RDL.hex -intel ^
  -crop 0x80002000 0x80040000 ^
  -offset -0x80002000 ^
  -o ../Firmware/rdl_flash.bin -binary

:(

Last Edited: Wed. Feb 15, 2012 - 11:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
BTW MD5 sounds like over-kill. I'd have thought CRC32 (which is what srec_cat does anyway) would be quite sufficient. MD5 in code is actually quite considerable - maybe 10KB..20KB?

I already have MD5 generator code in use for my PPP authentication session. So its costing me much :)

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

Quote:

ermm lol thats what I used to crop and make my firmware file... I didnt see any signature being added in that link or a CRC32 be appending...

unfortunately when I am trying to append at the begining a text file data, namely a header signature to the firmware file, its giving me grief...

luvocean1 check the batch file that is included in the app note.

Daniel Campora http://www.wipy.io

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

Ok I had forgotten that there was the additional lines for adding your signature at the begining of the file... I wonder why atmel chose those hex file bytes specifically, they dont seem to be the MD5 of "AVR32".

Anyways I am now able to make a binary file with those hex bytes and "AVR32" prepended.

I have written an MD5 program that you can run from command shell in windows. I can call this from the same .cmd file that I wrote up to call srec_cat. However if I try the following:

srec_cat ^
  ../Firmware/rdl_flash.bin -binary ^
  ../Firmware/rdl_flashmd5.bin -binary ^
  -o ../Firmware/rdl.bin -binary

I get:

srec_cat: ../Firmware/rdl_flashmd5.bin: 0x0010: contradictory 00000000 value (previous = 41, this one = 54)

rdl_flashmd5.bin is just a file holding the 16 bytes of MD5 hash in binary...

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

Yeehhaa just needed to add this line before the -o line

-offset -max ../Firmware/rdl_flash.bin -binary ^
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wonder why atmel chose those hex file bytes specifically, they dont seem to be the MD5 of "AVR32"

The string added at the beginning of the file is just a signature, but they also add a CRC32 at the end (didn't you see that??)... there is no need for MD5 in such a small file.

Daniel Campora http://www.wipy.io

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

Yes I realize but I already have codes written for MD5 on my device because of CHAP authentication during PPP...so I can just use that. :)

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

Yeah but, does srec_cat have a "generator" for MD5? It certainly does for CRC32.

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

no it doesnt but then again I quickly translated my MD5 code written on UC3A to Microsoft visual c++/c console code...so its a console exe program which you can call from cmd prompt or the .cmd batch file that runs the srec_cat stuff as well :)

So I now just run my .cmd script and I have a firmware which has the signatures prepended and the MD5 generated and appened to it. :D

Smart isnt it?