The bootloader uses the CRC module to verify the firmware image, and this part is working perfectly. However, the main firmware itself does not correctly reinitialize the CRC module when it starts up. As a result, any calls to calculate the CRC of data from within the firmware return zero.
There is extensive code related to the EEPROM settings storage that's designed to use CRC to verify the integrity of calibration data against corruption. As of now, this code is not accomplishing anything.
It is very important that any effort to fix this bug should also increment the version of any EEPROM settings pages using CRC and populate the CRC values as part of that upgrade. If this is not done very carefully, it could invalidate factory calibration on any devices that install code that re-enables the CRC module.
For now, it is very low priority to fix this. The risk of not detecting corrupted calibration data is, as of this time, considered much lower than the risk of invalidating existing calibration data as part of a firmware upgrade. This issue is mostly being written for reference purposes.
The bootloader uses the CRC module to verify the firmware image, and this part is working perfectly. However, the main firmware itself does not correctly reinitialize the CRC module when it starts up. As a result, any calls to calculate the CRC of data from within the firmware return zero.
There is extensive code related to the EEPROM settings storage that's designed to use CRC to verify the integrity of calibration data against corruption. As of now, this code is not accomplishing anything.
It is very important that any effort to fix this bug should also increment the version of any EEPROM settings pages using CRC and populate the CRC values as part of that upgrade. If this is not done very carefully, it could invalidate factory calibration on any devices that install code that re-enables the CRC module.
For now, it is very low priority to fix this. The risk of not detecting corrupted calibration data is, as of this time, considered much lower than the risk of invalidating existing calibration data as part of a firmware upgrade. This issue is mostly being written for reference purposes.