循環(huán)冗余校驗的核心數(shù)學算法原理基于循環(huán)碼，在不增加原始數(shù)據(jù)的信息基礎上擴展了信息，以極小的存儲代價存儲其冗余特征。該算法是W. Wesley Peterson 于1961年發(fā)明的。

• 這里的n位二進制數(shù)據(jù)為有效信息載荷。(可能是傳輸或存儲的有用信息)

• 根據(jù)CRC算法計算出m位冗余碼，即根據(jù)該CRC校驗多項式結合CRC算法從前面有效數(shù)據(jù)中提取出特征冗余碼，這就是冗余的真實含義。

• 實際傳輸或者存儲的就是n+m位二進制數(shù)據(jù)。

其基本的算法處理過程示意如下：

假定待發(fā)送有效數(shù)據(jù)為二進制多項式M(x)，而校驗多項式P(x)為收發(fā)雙方約定好了的，雙方已知，這里介紹一下幾個多項式表示的意思及相關處理流程：

接收方接收到數(shù)據(jù)后進行CRC校驗。余數(shù)為0，校驗通過。

其實CRC的本質(zhì)就是二進制多項式除法求取冗余碼的計算過程，無論軟件的查表法、移位計算法，還是純硬件邏輯電路實現(xiàn)，本質(zhì)都是一樣的。對于數(shù)字邏輯電路利用移位計算則更具優(yōu)勢，因為幾乎不占用CPU時間。

不同的校驗多項式，除了復雜度有差異外，從應用角度看有什么差異呢？從應用角度看主要體現(xiàn)在錯誤診斷率。不妨看看CRC-16以及CRC-CCITT的錯誤檢測效果：

• 可完全檢測出單bit及雙bit錯誤

• 奇數(shù)個位錯誤

• 能檢測出16位長度及小于16的突發(fā)錯誤

• 能以99.997%的概率檢測出長度為17位及以上的錯誤

由上文可見，CRC-8可診斷出99.6%的位錯誤概率，而CRC-16則提高至99.998%的位錯誤概率。

注：IEC61508是國際電工委員會功能安全標準(Functional safety of electrical/electronic/programmable electronicsafety-related systems)。

技術發(fā)展至今，已有大量不同的校驗多項式生成器被各行各業(yè)使用。下面是來自wikipedia截圖，供大家參考：

如下圖，STM32內(nèi)置了一個CRC-32硬件計算單元，實現(xiàn)了一個固定多項式0x4C11DB7（16進制表示），可應用于以太網(wǎng)報文校驗碼計算。

STM32 全系列產(chǎn)品都具有 CRC 外設，對 CRC 的計算提供硬件支持，節(jié)省了應用代碼存儲空間。CRC 校驗值既可以用于傳輸中的數(shù)據(jù)正確性驗證，也可用于數(shù)據(jù)存儲時的完整性檢查。在 IEC60335 中，也接受通過 CRC 校驗對 FLASH 的完整性進行檢查。在對 FLASH 完整性檢查的應用中，需要事先計算出整個 FLASH 的 CRC 校驗值（不包括最后保存CRC 值的字節(jié)），放在FLASH 的末尾。在程序啟動或者運行的過程中重新用同樣的方法計算整個 FLASH 的 CRC 校驗值，然后與保存在 FLASH 末尾地址空間的 CRC 值進行比較。

EWARM 從 v5.5 版本之后開始支持 STM32 芯片的 CRC計算。計算整個 FLASH的 CRC 校驗值并保存在 FLASH末尾的過程，可以在 IAR 中完成。通過配置EWARM 的 CRC 計算參數(shù)，自動對整個 FLASH 空間進行 CRC 計算，并將計算結果放到 內(nèi)部FLASH空間 的末尾。

或許你會問，這有什么應用價值呢？不妨以基于MCU程序的升級為例。在代碼升級過程中，如果不對bootloader升級接口傳入的二進制程序文件做校驗，就無法及時發(fā)現(xiàn)升級過程中發(fā)生的代碼錯誤。相反，如果原始代碼添加了校驗碼，升級程序在接受到升級文件后做校驗計算，并與待升級文件末尾的校驗碼進行比對，如果不匹配則放棄升級，這樣就不至于將無效的甚至有安全隱患的代碼寫進芯片。

• 修改 Link 文件，指定 checksum 在FLASH 中的存儲位置，在 Link 文件中增加下面語句。

place?at?end?of?ROM_region?{?ro?section?.checksum?};????

該語句指定將 CRC 的值放在 FLASH 空間的末尾位置。是整個 FLASH 空間的末尾，不是應用程序的代碼末尾。這樣，CRC 值的位置就是固定的，不會隨代碼大小而變化。?

• 配???????????????????置 Checksum 頁面的參數(shù)

IAR Checksum 頁說明（v6.4 及以上）

IAR 的 checksum 頁面分為兩個部分:

• 紅線圈出的部分：定義了FLASH 中需要計算 CRC 的范圍和空閑字節(jié)填充值。

• checksum 計算參數(shù)的設定部分：
  Checksum size ：選擇 checksum 的大?。ㄗ止?jié)數(shù)）
  Alignment：指定 checksum 的對齊方式。不填的話默認 2 字節(jié)對齊。

  Algorithm：選擇 checksum 的算法

  Complement：是否需要進行補碼計算。選擇“As is”就是不進行補碼計算。

  Bit order：位輸出的順序。MSB first，每個字節(jié)的高位在前。LSB first，每個字節(jié)的低位在前。

  Reverse byte order within word：對于輸入數(shù)據(jù)，在一個字內(nèi)反轉各個字節(jié)的順序。

  Initial value：checksum 計算的初始化值?

  Checksum unit size ：選擇進行迭代的單元大小，按 8-bit，16-bit 還是 32-bit 進行迭代。

• STM32 CRC 外設使用默認配置時 IAR 的配置

POLY= 0x4C11DB7（CRC32）?

Initial_Crc = 0Xffffffff?

輸入/輸出數(shù)據(jù)不反轉?

輸入數(shù)據(jù)：0x08000000~0x0801FFFB。(最后 4 個字節(jié)用來放計算出的 CRC 值)

在實驗的過程發(fā)現(xiàn)， ”Alignment ”似乎對計算出的 CRC 值沒有影響。但“Reverse byte order within word ”與“Checksumunit size ”這兩項的配置有一定關系。如果后者選擇 32-bit，則不能勾選前者；反之如果后者選擇 8-bit，則一定要勾選上“ Reverse byte order within word ”。也可以參照下圖進行設置：

對于IAR v6.4 以下版本，沒有”Checksum unit size”選項。參考配置如下：

/*-1- 配置CRC外設 */  CrcHandle.Instance = CRC;   /* 默認二進制多項式使能 */  CrcHandle.Init.DefaultPolynomialUse = DEFAULT_POLYNOMIAL_ENABLE;   /* 默認初值設置 */  CrcHandle.Init.DefaultInitValueUse = DEFAULT_INIT_VALUE_ENABLE;   /* 輸入數(shù)據(jù)不反轉 */  CrcHandle.Init.InputDataInversionMode = CRC_INPUTDATA_INVERSION_NONE; 
 /* 輸出數(shù)據(jù)不反轉 */  CrcHandle.Init.OutputDataInversionMode = CRC_OUTPUTDATA_INVERSION_DISABLED;   /* 輸入數(shù)據(jù)基本單元長度為32bit */  CrcHandle.InputDataFormat = CRC_INPUTDATA_FORMAT_WORDS;   if (HAL_CRC_Init(&CrcHandle) != HAL_OK)  {  /* 初始化錯誤 */  Error_Handler();  }   pdata = (uint32_t*)ROM_START;   /*##-2- 調(diào)用HAL庫利用硬件CRC外設對ROM區(qū)計算CRC-32校驗碼*/  uwCRCValue = HAL_CRC_Calculate(&CrcHandle, pdata, ROM_SIZEinWORDS);

• 將塊數(shù)據(jù)利用CRC算法計算出冗余碼，有的文章、標準稱這個冗余碼為簽名。實際應用時計算有效數(shù)據(jù)所得校驗碼與預存校驗碼進行比較，相等則校驗通過，反之則失敗。當然，也可以將原數(shù)據(jù)與所存校驗碼一起傳入校驗算法，所得結果為0則校驗通過，反之失敗。
• 對于數(shù)據(jù)通信，一般會在報文的尾部添加有效數(shù)據(jù)的校驗碼，再由接收方校驗收到報文的數(shù)據(jù)完整性。

-END-