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.
:
Verschoben durch Moderator
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.