CRC generierung mittels srec_cat

Adib Gast #2822964
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Andreas Gast #3021624
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #3021662
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas Gast #3022606
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas Gast #3743569
Lesenswert?
• ▲
▼ 
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
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren