Post Go back to editing

Checking the integrity of the program firmware by checksum while the software is running

Good day!

We had the following problem: it is necessary in the background during the technology operation to check the compliance of the checksum of the flashed code with the one calculated for the current program call by the current state of the program memory. In this regard, I ask you to answer a number of questions:
1) where is the firmware loaded from ROM located in RAM during the program execution and is there access to it in the background?
2) is it possible to write the firmware to the ROM along with the checksum calculated externally (for example, by the cyclic checksum algorithm), and how to get access to the recorded checksum value while the program is running?
3) is it possible to automatically check the firmware integrity by checksum and at what points: during restarts or in the background with a specified test period?

Many thanks,
Sergey Chernov

  • Hi Sergey Chernov,

    I assume you are referring to the ADSP-BF70x family of processors.

    The ADSP-BF7xx features CRC32 protection which is implemented in hardware. The boot kernel provides mechanisms to allow each block to be verified using a 32-bit CRC. The boot rom contains a function in the rom that can be called as an initcode to register the CRC callback and initialize the CRC peripheral with a user specified polynomial. To enable this feature an Init Block must be located in the boot stream with a TARGET_ADDRESS that points to the adi_rom_Crc32Init() function in the ROM. The ARGUMENT field contains the CRC32 checksum polynomial to be used to initialize the CRC lookup table. Once this CRC initcode function in the ROM has been executed CRC verification is enabled for all subsequent blocks except Ignore and First block.

    The utilities provided by the supporting toolchain for the processor allow for generation of CRC32 protected loader streams. When building a LDR file for CRC32 protection, use the -CRC32 <PolynomialCoefficient> switch. The -CRC32 switch directs the loader to generate CRC32 checksums. It uses the polynomial coefficient if specified, otherwise uses the default coefficient (0xD8018001).

    Anand Selvaraj.

  • Thank you so much for your response. You have answered questions 2 and 3 from the list given in the original email.

    As I understand it, there is no exact answer to the question where the firmware of the program code from ROM to RAM is placed in the processors of the ADSP-BF70x family? And there is no way to access every byte of the firmware code through RAM during the program?

    If this is not the case, please specify the parameters, where exactly is the firmware code placed during the operation of the program and how to access it byte-by-byte? Thank you in advance!

  • Hi Sergey Chernov,

    Apologies for the delayed response. Not sure if your issue is still open.

    From your mail, I understand that you want to access each byte of the loader stream and verify CRC for the stream. Please correct if my understanding is wrong.

    The CRC peripheral allows for the initialization and verification of regions of memory. The peripheral supports efficient memory-fill and verification operations on regions of memory with or against a constant value. As already mentioned, while generating the loader stream use the -CRC32 <PolynomialCoefficient> switch. This will generate the loader with CRC. After generating the loader stream, you can use the stream to verify if its CRC matches with expected CRC. The CRC_COMP register contains the value corresponding to the expected CRC result or signature for the current data stream. At the end of the operation, the content of this register is used to compare against the result produced by the CRC operation. The CRC compare error is generated when the signatures do not match.

    For your reference, I'm attaching a simple CRC example code available in my repository. This code can be directly run on ADSP-BF707 Ezkit.

    Anand Selvaraj.