Hi all,
A little background: I've cobbled together a firmware-updating boot loader for an 8051-based board from application notes. The firmware can receive a firmware image in 128-byte blocks over uart. Each of the blocks is CRC16 checked and this all works great. Now, to be doubly sure, I was thinking I should hash the entire file at the end of receiving the blocks and verify before flashing.
I was looking at MD5 for hashing the file and have found source for it. Unfortunately, when I implement it, I get incorrect hashes/results. I presume the problem is a combination of endian differences and 'int' sizes being different. Even after attempting to correct that, my results are incorrect. I've noticed a few threads mentioning a Graham Cole that ported md5 in a nice compact (and working!) way, but I can't find any source for that solution, I presume he can't be contacted anymore (some people mentioned they tried).
On to my question(s):
1) does anyone have a version of md5 ported for 8051? Or Graham Cole's solution? 2) Is md5 a good fit for what I'm trying to do? 3) OR- I being overly paranoid? Is the CRC16 of each block (and numbering the blocks for order) good enough?
Perhaps he doesn't work for BT anymore?
Yes, MD5 does seem like overkill.
A CRC32 across the entire firmware image should be more than adequate to provide a secondary check to the XMODEM CRC16
Ok, he doesn't, but Andy knows him.
Sending email to addresses at former employers frequently ends up in a bit bucket, and almost never to the original recipient. Find a current address, and use that.
He certainly doesn't.
Although the MD5 solution probably does still belong to BT.
Anyhow, I agree that it's probably overkill; an overall CRC32 should be fine - especially with blocks being individually CRC-protected
The need for more advanced checksumming increases with project size.
But 8051 programs are quite tiny so multiple CRC-16 + a final CRC-32 is fine. I use that in a number of microcontroller projects (CRC-16 for each transfer block and CRC-32 for the full file) and have still never seen any indication of a missed error.
Porting the MD5 to different processors shouldn't really be an issue as long as the correct data sizes are used. There should normally not be any endian issues - the data is processed byte-by-byte, and the digest is a 16-byte array that is assigned byte-by-byte. But there might be issues if the 8051 compiler isn't configured for standard-compliance integer promotion rules.