MSP430FR5969: ROM checksum

It is a tricky problem. You need to include the checksum in the image but you can't do that before you have an image.

Probably the simplest way to compute it is from a .hex file (msp430-elf-objcopy -O ihex). Then manually patch that value in. Which brings up the problem of where to put it. I suggest one of the unused interrupt vectors. Assuming those aren't included in the checksum.

Another approach would be to store the checksum in information memory. This does not require patching the .elf file. The first time through the code notices that the information memory is blank and just stores the checksum. After that it compares them and reports any differences.

Hi,

over which memory range you want to calculate the checksum is it really the ROM where the BSL is located (0x1000-0x17FF). Here it is easy because the memory will not change you can calculate it in your code with the CRC once and take the value for comparison. It will never change. For CRC calculation you can use the onchip CRC module.

If you want to do this over your FRAM memory it is only possible over the program code and not the part of the variables. Once you calculated it you can store it a memory location outside your calculation range. If you code section will not change during runtime it will stay constant. Even here you can use the CRC module.

The (CCS) linker will generate CRC(s) for your code as it's built. It is done on a per-section basis. [Ref Assembly Language Tools (SLAU131U) Sec 8.9]

Your application will need some code to compute the CRC at run-time. I adapted the code from SLAA221A (there's a link inside the .PDF).

Here's an overview:

https://e2e.ti.com/blogs_/archives/b/toolsinsider/archive/2017/02/27/from-the-experts-perform-cyclic-redundancy-checking-using-linker-generated-crc-tables

Thanks for the info! On the PC/build side I'm using MSP430-GCC so unfortunately I won't be able to use the CCS linker. Do you have any experience with that checksum functionality outside of CCS? I reviewed the MSP430-GCC docs but didn't see anything referencing section CRCs.

On the target side, the approach described in the linked information seems reasonable but I'll need to investigate a bit more to adapt it for my application.

Apologies for the confusion, by ROM I meant the text section and any rodata sections. I'm still working on how to calculate each section during run time and how the results should be handled.

Another user mentioned that the TI CCS linker automatically generates section CRCs during build time. Are you aware of any equivalent functionality for the MSP430-GCC build system?

Based on my understanding, computing a CRC for the entire image on the build side would also include data sections that are dynamic during run time. This would make it nearly impossible to checkout on the hardware because the data in those sections changes and therefore would produce a non matching CRC. I think finding a way to checksum only the program code and read only data is my best bet. Is that what you meant in your explanation of the information memory approach?

Yes. Find appropriate symbols for the beginning and end of code/rodata and compute the CRC.  Then compare to the previous value in information memory.

You do have to take care to erase information memory each time you program the device so that the new value can be stored. This depends on that first run after programming having a good chance of not having any errors.

If you are really concerned about errors you should probably worry about infrequently run code. The FRAM system includes ECC and can correct some read errors automatically. But only if you read it. So a task that runs every day or three that simply reads all of FRAM, or at least your code/rodata, might be useful. (The CRC routine would work.) As well as enabling those FRAM controller interrupts for uncorrectable errors.

update: It seems that the PC side CRC utility discussion is becoming software specific so I posted a new question directly about the MSP430-GCC compiler/linker. I tagged it as related to this post so that any helpful information will still be linked together across threads.