So to sum them would take 8+11 = 19 bits. In WinAVR there is a PDF version that pulls all the 'man' pages together than makes things easier to find.īNow I am waiting for the OP to give me permission before I go hijacking another thread I agree the way the manual is just made up of 'man' pages does not make it that easy to follow. hex file they know they have programmed the correct version of code successfully. If that matches what you told them when you sent the. They program the code into a device then read it out again and get the checksum. But who was talking about summing SRAM? We're talking about checksums of flash here. So it would require 11 bits am I right here?Ģ56 is 2^ is 2^11 so to sum them would take 8+11 = 19 bits. But if you are just 'adding up the bytes' why do you feel the need to squeeze it into 8bits? Why not a 16, 32, 64 bit sum?Īn Atmega328P has 2048 bytes of data memory so the checksum for all that could theoretically be a maximum of 2048*0xFF/0xFF Well, yeah, if you only sum into an 8bit then the result clearly cannot be more than 0.255. I did work it out eventually and my decoder (at least of their -l-e-cr16) is built into this: The only thing I ever found an 'issue' in srec_cat was working out the polynomial, starting value and augmentation of the CRC they actually use. hex file processing program to achieve similar the fact is that SRecord (the global name for the group of programs that includes srec_cat) does pretty much anything you can ever think of to. While one could easily use libbfd to write your own. Then you list the operations to be performed on that buffer such as cropping it or expanding it or calculating a checksum and embedding it in there etc. You first have it load a file into a buffer (it can read about 30+ different code formats). In fact you should think of the srec_cat command line as almost a linear flow of programming operations. There's also -crop which you can use to limit the region that it operates on to some specific address range. It can do all sorts of checksums and CRCs.īy default it will just checksum the data from input file but if you add a -fill on the command line you can instruct it to extend the data and virtually fill the remaining space with any value which would include 0xFF (the value in erased but unused flash bytes).

Oh and I only picked a big endian CRC16 as an example. Please Lee, I would really appreciate your comments on this as well as the other freaksĭid you miss my suggestion of srec_cat? Have you looked at the manual?

Hex file crc 16 calculator checksum