This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FLASH CHECKSUM COMPUTATION (PROCESSOR ARM CORTEX M0, FLASH 16MB)

Hello, I am working on a project with ARM Cortex M0 processor. I am totally new to the concept of ARM and its processor, (but the project requires it). I already have the application files made and I am writing them into flash (downloading it into flash). I was asked to write a program to compute the checksum for the FLASH (size 16MB) . The application uses the flash to store the code as well as to store data. Inorder to compute the checksum as mentioned above what should I do?
< I am sorry if the question is unclear, unfortunately I am also @ odds here ...but please let me know if u have any possible suggestions for the above case, any methods to achieve the same OR if the question needs to be clarified or anything>

Thanks in advance

  • I was diding something like this.

    I wroted a program to read in the code image to memory. Calculate the CRC of it. Appending the CRC to the memory image. Writed the image to a new file.

    In the processor application it readeds the code image with the CRC and verifies it. It only uses the image if the CRC is goodly.

    I have dided this with ARM and x86 and other codes. It is being a concept not just for Keil.

    When i first dided it the file only haded the CRC. It checking for corruption. I now addeding other bits to check for people to trying to hack the files and stoped them doing badly things. I using MD5 and other stuff for this.

  • But you presumably have some C programming proficiency? Say basic data representation, and file IO?

    Keil can generate .HEX files via a check-box item, and .BIN files using the FromELF tools as a post-link User step.

    You could post-process .AXF(ELF), .HEX or .BIN data and sign that with the appropriate check sum, CRC, MD5, SHA, etc.

    People have written tools to do this over the years, I know IAR has some options, but frankly a lot of this type of signing/packaging of firmware images tends to be proprietary and tailored to specific parts and company policies.