STM32 CRC mit 3 Byte Daten

[Martin (Gast)]

Hi,

ich bin gerade dabei mein Kommunikationsprotokoll über UART zu erweitern 
um CRC.
Das klappt aber nur in bestimmten fällen:
Ich habe folgende Funktion auf dem STM32F103:

uint32_t CRC_CalcBlockCRC_8(uint8_t* data, uint32_t len)
{
  uint32_t* pBuffer = (uint32_t*)data;
  uint32_t BufferLength = len / 4;
  uint32_t index = 0;

  for (index = 0; index < BufferLength; index++)
  {
    CRC->DR = __RBIT(pBuffer[index]);
  }
  return __RBIT(CRC->DR) ^ 0xFFFFFFFF;
}

Die Funktion hilft mir dabei, aus einem uint8_t Array die CRC32 mithilfe 
des CRC-Registers des STM32 zu berechnen. Solange len ein Vielfaches von 
4 ist, klappt das wunderbar. Ist len % 4 != 0, kommt keine korrekte CRC 
mehr bei raus.
Ich habe bereits versucht ein eigenes Array anzulegen, das Array mit 
0x00 zu füllen, anschließend die Daten rein zu kopieren und dann immer 
ein Vielfaches von 4 an die Funktion zu übergeben.
Mit dem Online-Calculator von 
https://www.lammertbies.nl/comm/info/crc-calculation.html bin ich dann 
darauf gestoßen, dass bei einem Array-Inhalt in der Art von "0x01, 0x01, 
0x07" auf dem µC die Checksumme raus kommt für "0x01, 0x01, 0x07, 0x00".

Wie kann ich das verhindern? Wie kann ich (ohne immer leere Daten 
schicken zu müssen) mit der integrierten CRC des STM32 die richtige 
Checksumme berechnen wenn ich, wie in meinem Beispiel, nur 3 Byte Daten 
habe?

[nicht"Gast" (Gast)]

Nur so ne Idee.

rechne deine 8Bit CRC auch nur mit 8Bit breiten Datentypen.

[Sebastian V. (sebi_s)]

Nach dem Datenblatt scheint die CRC Funktionalität nur in ganzen 32Bit 
Blöcken zu arbeiten. Von daher würde ich sagen, dass es schlecht 
aussieht. Mir ist nicht bekannt das man die fehlenden Bytes mit 
irgendwas einfachem auffüllen könnte um die Checksumme nicht zu 
verändern. Bleibt also nur die Daten auf vielfache von 4 Byte 
aufzufüllen oder die CRC Berechnung in Software zu machen (wenigstens 
für den letzten unvollständigen Block).

[Patrick J. (ho-bit-hun-ter)]

Hi

Wenn Du doch nur 3 Byte per CRC prüfen willst, brauchst Du da eine 32bit 
Prüfsumme?

Habe die Prüfsummen-Routine für den DS18B20 leider auch nur kopiert 
(geht mir halt nicht in den Kopf), soll halt für 'viele Daten' 
ungeeignet sein, was ich gelesen habe.
Vll. kannst Du damit was anfangen, ist allerdings Assembler :/

; ATmega8                    
; [e-mail]            
; 06/2012                    
; ##############################################################################
; ##############################################################################
; ##############################################################################
; CRC Berechnung übernommen und abgeändert von: http://s-huehn.de        
; CRC-Berechnung Application Note 27 von Dallas/Maxim              
;                                        
; zu berechnende Daten  ow_Data (sRam)
; CARRY bei CRC-Fehler, sonst Carry gelöscht
;                                        
ow_CRC8:        ;meinem Verständnis nach, berechnet die Routiene eine CRC8 Prüfsumme, Name auf '8' geändert
  push XL            ;auf dem Stack sichern            
  push XH
  push r16
  push r17
  push r18
  push r19
  push r20
  push r21
;ONE_WIRE_ROM_CRC7_RUN:            ;wenn erneut berechnet werden soll, dann hier einspringen
  ; INITIALISIERUNG
   ldi XL,low (ow_Data) ;Zeiger         
    ldi XH,high(ow_Data) 
    ldi     r19, 8                          ;7 Bytes berechnen für ID nebst CRC, 8 Bytes für Scratchpad
                      ;wenn eine ID geprüft werden soll, erstes Byte 00, restliche 8 Byte ID
                      ;dahinter, da führende Nullen bei der CRC keine Änderung hervorrufen
    ldi     r20, 0x18                       ;Konstante für Berechnung
    clr     r17                            ;CRC-Startwert = 0 setzen
;ONE_WIRE_CRC7_100: 
  ld      r18, x+                         ;Byte aus Puffer holen
    mov     r21, r18                        ;Byte zwischenspeichern
    ldi     r16, 8                          ;8 Verschiebungen
;ONE_WIRE_CRC7_200: 
  eor     r18, r17                        ;CRC berechnen
    ror     r18                             ;Ergebnis in Carry schieben
    mov     r18, r17                        ;letzten CRC-Wert holen
    ;brcc    ONE_WIRE_CRC7_300                          ;war Ergebnis = 0? ja -> weiter
  brcc    PC+2                            ;war Ergebnis = 0? ja -> weiter
    eor     r18, r20                        ;sonst CRC-Wert updaten
;ONE_WIRE_CRC7_300: 
  ror     r18                             ;neuen CRC-Wert positionieren
    mov     r17, r18                        ;und speichern
    mov     r18, r21                        ;restliche Bits holen
    bst     r18, 0                          ;LSB sichern, nächste Bitposition
    ror     r18                             ;gesichertes Bit als MSB einsetzen
    bld     r18, 7                          ;(Ersatz für RR-Befehl)
    mov     r21, r18                        ;und Wert zwischenspeichern
    dec     r16                             ;alle Verschiebungen erledigt?
  brne    PC-13  ;ONE_WIRE_CRC7_200      ;nein -> Schleife
    dec     r19                             ;alle Bytes bearbeitet?
  brne    PC-18  ;ONE_WIRE_CRC7_100      ;nein -> Schleife
;-------------------------------------------------------------------------------
;  hier ist die CRC-Summe berechnet, mit empfangenem Wert überprüfen
  LDS temp,(ow_Data+8)
  ; ev. Korrektur
  ;STS(ow_Data+7),R17    ;eigentlich unnötig
  cp temp,r17
  brne PC+3  ;ONE_WIRE_CRC7_ERROR
  CLC                    ; CARRY=0 für 'CRC ok'
  rjmp PC+2  ;ONE_WIRE_CRC7_FERTIG
;-------------------------------------------------------------------------------
;ONE_WIRE_CRC7_ERROR:
  ;ggf Fehlerausgabe ect.pp.
  ;dann müssen aber die Sprünge angepasst werden
  ;da vor dem Test der berechnete CRC-Wert im Speicher abgelegt wurde (sofern das STS nicht geremmt ist), würde eine erneute Berechnung 'CRC ok' bringen - weshalb erschließt sich mir nicht, da die Daten ja wohl zuvor fehlerhaft übertragen wurden
;  rjmp ONE_WIRE_ROM_CRC7_RUN    ;die erneute Prüfung ist deshalb geremmt, da ohne STS erneut CRC-Fehler und mit STS definitiv kein CRC-Fehler, da CRC selber zusammen gerechnet und überschrieben
  SEC                    ;für 'CRC-Fehler'
;-------------------------------------------------------------------------------
;ONE_WIRE_CRC7_FERTIG:
  pop r21                    ; wiederherstellen                  
  pop r20
  pop r19
  pop r18
  pop r17
  pop r16
  pop XH
  pop XL
ret

Ich habe die erneute Berechnung auskommentiert, da, wenn die Daten 
falsch empfangen wurden, eine erneute Prüfung ebenfalls nur zu einem 
CRC-Fehler führt und das Programm sich dann aufknüpft, da immer wieder 
die Berechnung durchgeführt wird.

Auch ist in den Kommentaren ersichtlich, daß führende Null-Bytes keine 
Auswirkung auf die Prüfsumme haben - eine unterschiedliche Anzahl von 
Null-Bytes am Anfang geht also gar nicht in die Berechnung ein.
CRC von 00 00 00 (oder beliebig viele 00er mehr) -> 00

MfG

[Sebastian V. (sebi_s)]

Da kann man sich vermutlich besser den Code auf Wikipedia anschauen: 
https://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung#Berechnung_einer_CRC-Pr.C3.BCfsumme_in_C_und_Pascal_bzw._Delphi

Dort wird im ersten Beispiel auch schnell klar, dass 0 Bits am Anfang 
die Checksumme nicht verändern (Shiften von 0 bleibt 0). Allerdings ist 
die CRC Variante im STM32F1 wohl die aus dem zweiten Beispiel wo der 
Startwert auf 0xFFFFFFFF initialisiert wird. Hier ist es etwas 
kniffeliger.

Das Invertieren des Startwerts hat laut Wikipedia den gleichen Effekt 
wie das Invertieren der ersten 4 Bytes. Aus dem einfachen Voranstellen 
von 0x00 Bytes werden also 0xFF Bytes und zusätzlich müssen alle Bytes 
die vom ersten 4 Byte Block in den zweiten gerutscht sind invertiert 
werden:

   11 22 33 44 55 66 77
FF 11 22 33 BB 55 66 77

Diese beiden Blöcke liefern nun die gleiche CRC Summe. Bei weniger als 4 
Bytes füllt man ebenfalls auf mit 0xFF am Anfang auf 4 Bytes auf und 
muss anschließend in der CRC Summe die Bits flippen die durch die 
führenden 0xFF auf 0 gesetzt wurden.

[Martin (Gast)]

Perfekt, vielen dank Sebastian!
Da wäre ich so nie drauf gekommen :)

Funktioniert mit diesem Schema auch mit 5 oder 6 Daten-Bytes.

[Sebastian V. (sebi_s)]

Sollte für beliebig lange Daten funktionieren. Habe ich allerdings nicht 
alles ausprobiert.