Hallo,
Ich möchte gern vom bootloader mein Applikations-Image mittels CRC16
prüfen.
Dazu wollte ich die CRC16 der Image-Datei bilden.
Ich benutze folgenden Aufruf
>srec_cat output.bin -binary -crop 0 10 -crc16_b_e 0x10000 -POLYnomial ibm -crop
0x10000 0x10002 -o - -hex-dump
Ich kann die generierte CRC aber mit anderen Tools nicht bestätigen.
Jetzt habe ich eine datei gebildet mit dem Inhalt "1234567890" - 10
Bytes.
Ich teste online mittels
http://www.lammertbies.nl/comm/info/crc-calculation.html
Und dann habe ich mir noch ein tool geschrieben mit dem Algorithmen aus
der AVRlib
http://www.nongnu.org/avr-libc/user-manual/group__util__crc.html
Bei den meisten CRC Versionen stimmen die Werte nicht überein, nur bei
XMODEM habe ich in allen drei Verfahren gleiche Werte.
Avrlib
CRC16 c20a (Startwert 0xffff)
CCITT b4ec (Startwert 0xffff)
XMODEM d321 (Startwert 0)
Web
CRC16(Modbus) c20a
CCITT(0xFFFF) 3218
CCITT(XMODEM) d321
SREC_CAT
IBM 4ce7
CCITT 57d8
XMODEM d321
Da ich eigentlich sreg das Ausrechnen meiner CRC16 überlassen wollte,
möchte ich gerne wissen, warum ich bei CRC16(IBM) und CCITT so andere
Werte bekomme?
Könnt ihr mir weiterhelfen?
Danke, Adib.
Hallo Adib,
ich habe exakt das gleiche Problem. Mit der XMODEM-CRC bekomme ich
(zumindest bei einer Variante davon) das korrekte Ergebnis.
Ich habe nun alle möglichen Parameter in allen Kombinationen in srecord
(V1.59) getestet (-Least_To_Most, -No-AUG,...).
Mit CCITT und CRC16 bringe ich aber auch kein passendes Ergebnis
zusammen (zumindest nicht zwischen srecord und avr-libc).
Ich verwende übrigens WinAVR-20100110 (gcc 4.3.3).
Folgende zusammenpassende Ergebnisse habe ich (abgesehen von XMODEM)
auch mit etwas herumspielen hinbekommen:
avr-libc (CRC16) = web (CRC-16 (Modbus))
srecord (CRC16) = web (CRC-CCITT (0x1D0F))
Hast Du schon mehr rausgefunden?
Gruß,
Andreas
Andreas schrieb:> Mit CCITT und CRC16 bringe ich aber auch kein passendes Ergebnis> zusammen (zumindest nicht zwischen srecord und avr-libc).
CCITT ist für Übertragungsprotokolle konzipiert. Diese übertragen
allesamt das LSB zuerst, d. h. sie werden in den Standards anders
herum aufgeschrieben, als unser Auge das gewohnt ist (Bit 0 steht
immer ganz links). Dem muss man bei der Abarbeitung des Algorithmus
Rechnung tragen.
Im Prinzip benutzen CCITT (das letztlich auf X.25 zurück geht)
und Xmodem das gleiche CRC-Polynom, nur eben mit vertauschter
Bitreihenfolge.
Mir hatte neulich jemand einen Bugreport für die avr-libc angefertigt,
in dem er dieser eine fehlerhafte Implementierung unterstellt hat.
Da ich aus eigener Erfahrung wusste, dass ebendiese Implementierung
bereits erfolgreich bspw. für IEEE 802.15.4 getestet worden ist, habe
ich die Details mal recherchiert:
https://savannah.nongnu.org/bugs/?37901
einschließlich des Ursprungs im X.25. Fazit: die avr-libc-Implemen-
tierung tut exakt das, was auch in X.25 als Testvektor dokumentiert
ist (wobei dort noch Füllbits reinkommen und die CRC negiert
übertragen wird, sodass am Ende nicht mehr 0 rauskommt). Damit kann
sie sich das Etikett "CCITT" ankleben ;-), egal, ob andere Programme
den CCITT-Algorithmus nun genauso interpretieren oder nicht.
Nicht vergessen: manche Algorithmen fangen mit einem Vorgabewert von
0 an (was den Nachteil hat, dass die CRC 0 bleibt, wenn die Datenbytes
alle 0 sind), andere fangen mit 0xffff an. Der originale X.25-
Algorithums fängt beispielsweise mit 0xffff an, während 802.15.4
(trotz gleichen Polynoms und gleicher Bitreihenfolge) mit 0 anfängt.
Der Initialwert liegt jedoch außerhalb des Einflusses der Bibliotheks-
routine. Schließlich noch, siehe X.25, könnte es sein, dass die
CRC selbst bitweise negiert ausgegeben wird.
Hallo Jörg,
vielen Dank für die ausführliche Info. Der Tipp mit der negierten
Checksumme hört sich besonders interessant an. Ich schau mir das morgen
genauer an.
Gruß,
Andreas
Andreas schrieb:> Der Tipp mit der negierten> Checksumme hört sich besonders interessant an.
Ja, ist schräg, aber scheint gar nicht so unüblich zu sein. Habe ich
letztens bei IEEE 802.15.4g gesehen, und danach fiel mir die
X.25-Spec in die Hände, die das genauso machen.
Hallo,
auch mit inversen, negierten und gespiegelten (Bitreihenfolge MSB<->LSB
umdrehen) CRCs halten sich mein Erfolge in Grenzen. Ich werde jetzt mal
etwas genauer recherchieren - wird jedoch etwas dauern. Das Dokument "A
PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" wird öfter im
Zusammenhang mit srecord genannt. Vielleicht kann es etwas Licht ins
Dunkel bringen. Wenn ich mehr weiss, werde ich erneut posten.
Gruß,
Andreas
Hallo,
hat nun wirklich eine Weile gedauert (bin vorübergehend auf XMODEM-CRC
ausgewichen), aber ich hab's nun hinbekommen.
Folgende CCITTs stimmen nun überein:
srec_cat (V1.64) == code (_crc_ccitt_update von avr-libc V1.8.0) ==
Online Calculator (http://www.zorc.breitbandkatze.de/crc.html).
Ich habe das script für srec_cat, das source-file mit dem Test-Code und
Screenshots vom Online Calculator (Varianten, die alle das gleiche
Ergebnis liefern) und die readme zusammengepackt. Vieleicht hilft es
jemandem weiter.
Mein größtes Problem war die Verwendung des Kommandozeilenparameters
"-NO-AUGment" in srec_cat, an dem ich bis vor kurzem festgehalten habe.
Sobald aber auf die Augmentierung in srec_cat verzichtet wird, stimmt
das Ergebnis nicht mehr mit meinen anderen
(Non-Augmented-)Vergleichsquellen überein. Wenn ich den Grund dafür
finde, werd ich wieder posten - auch wenn's nochmal 18 Monate dauert :)
Gruß,
Andreas
