CRC8 - Zu dumm für die Gegenrechnung?

[Martin S. (sirnails)]

Hallo miteinander,

ich stehe ziemlich auf dem Schlauch.

Ich habe einen MLX90614 IR-Temperatursensor. Dieser übermittelt mir 
meine Temperatur als 2 Byte + 1 Byte Prüfsumme. Dabei ist die 
Reihenfolge MSB LSB CRC.

Das Generatorpolynom ist nach ITU-T: x^8 + x^2 + x^1 + 1

Aus dem Datenblatt habe ich mir die Datenfolge "8b b9 43" 
herausgeschrieben.

Um gegenzuprüfen, müsste ich also rechnen:

(1000 1011 1011 1001 0100 0011) XOR (1 0000 0111).

Wie ich es aber drehe und wende, ich komme nie auf 0, sondern immer auf 
0100 0100.

Auch mit selbst empfangenen Werten, mit MSB/LSB vertauscht, komme ich 
auf irgendwas sinnvolles.

Kann mir jemand sagen, wo mein Denkfehler ist?

Grüße

M. Schwaikert

[Lattice User (Gast)]

Aus der SMBUS20 (smbus.org/specs/smbus20.pdf) Spec:

The PEC is appended to the message as dictated by the protocols in 
section 5.5. The PEC calculation includes all bytes in the transmission, 
including address, command and data. The PEC calculation does not 
include ACK, NACK, START, STOP nor Repeated START bits. This means that 
the PEC is computed over the entire message from the first START 
condition.

[Martin S. (sirnails)]

Hmm.. das habe ich jetzt mal probiert, nur leider komme ich nach wie vor 
auf kein schlüssiges Ergebnis:

Befehl: s b4 07 s b5 03 p

        S-Adr  R/W   ADR      S-ADR R/W   ADR
Binär: 1011010  0  00000111 1011010  1  00000011

Dieser Befehl ließt aus dem RAM den Datenwert.

Empfangen wird: 82 39 35

Oder Binär: 1000 0010 0011 1001 0011 0101

Ergibt als Berechnung:

(1011 0100 0000 0111 1011 0101 0000 0011 1000 0010 0011 1001 0011 0101) 
XOR (1 0000 0111)

Aber auch hierbei kommt kein sinnvolles Ergebnis heraus, zumal die 
Division nicht vollständig aufgeht.

Hat jemand dazu eine Idee?


Grüße M. Schwaikert

[Tiramisu (Gast)]

Deine Notation deutet darauf hin, dass keine "Division" (=Rest)
ausgefuehrt wird:

(1011 0100 0000 0111 1011 0101 0000 0011 1000 0010 0011 1001 0011 0101)
XOR (1 0000 0111)
~~~

Das XOR sollte MOD heissen. Die "Division" ist uninteressant,
es ist der Rest der Division welcher interessiert.

[Martin S. (sirnails)]

Ja Verzeihung, das Stimmt wohl.

Ich habe inzwischen festgestellt, dass die Notation des Befehls auch 
falsch ist. Eigentlich müsste dieser lauten:

s b4 07 r03 p

Baustein mit Adresse 1011 010
Lesezugriff 0
mit der Adresse im RAM des Bausteins 0000 0111 (0x07)

Ergibt: 1011 0100 0000 0111

Der Sensor liefert zurück:

c8 39 ec

Also:
Lower Byte 1100 1000
Higher Byte 0011 1001
CRC 1110 1100

Ich habe diesen Messwert 10x hintereinander mit zeitlichem Abstand 
abgefragt und es kam jedes mal das selbe Ergebnis. Dennoch geht die 
Polynomdivision mit dem Generatorpolynom nicht auf.

Da ein Fehler auszuschließen ist, liegt es wohl daran, dass ich nicht 
genau nachvollziehen kann, ob der USB<->I²C-Controller nicht 
irgendwelche Bits verschluckt bzw. ändert, oder welche Worte nun genau 
in die CRC-Berechnung mit einfließen.

Laut Datenblatt der komplette gesendete Befehl + LOWER-Byte + 
HIGHER-Byte + CRC ohne ACK/NACK/STARTBIT/STOPPBIT mod Polynom. Die 
Division geht allerdings auch bei dieser Variante nicht auf.

[Lattice User (Gast)]

Vielleicht hilft dir das weiter:

http://smbus.org/faq/crc8Applet.htm

Wenn man die Webseite von Larry Page nach SMBUS und PEC fragt spuckt sie 
noch mehr nützliche Links aus.

[Martin S. (sirnails)]

Hallo,

vielen Dank für die Hilfe. Ich habe den Fehler inzwischen identifizieren 
können. Scheinbar erlaubt der SM-Bus keinen Direktzugriff. Daher 
erwartet der Sensor erst einen Schreibzugriff auf die Speicheradresse 
und danach einen Lesezugriff auf die Speicheradresse +1.

=> Gesendet: s b4 07 s b5 03p
Empfangen: d4 39 47

Aus b4 07 b5 d4 39 47 wird dann die Checksumme berechnet und ergibt 
richtigerweise 0.

... zwei Tage hat mich diese tolle Erkenntnis gekostet. Herrlich!

Grüße

M. Schwaikert.

[Lattice User (Gast)]

Martin Schwaikert schrieb:
> => Gesendet: s b4 07 s b5 03p

Ok, hätte auch mir schon vorher auffallen können:
Woher kommt die 03p?
Nach der b5 (Leseaddresse) muss direkt auf Empfangen geschaltet werden.

Zur Verdeutlichung: Das SMBUS Protokoll ist eine Erweiterung von I2C.

[Martin S. (sirnails)]

03 ist die Menge an Bytes, die vom Sensor erwartet werden. p ist die 
Schlusskennung. Das scheint so eine Eigenheit von der ELV Box zu sein. 
Vielleicht kannst Du mir aber erklären, warum ich die Adresse, sowie die 
Adresse +1 übergeben muss.

Grüße M. Schwaikert

[weinbauer (Gast)]

Sub_crc8 = 0
         For Tmp_byte = 1 To 5
                  Sub_x = I2c_array(tmp_byte)
                  For Sub_k = 0 To 7
                                    Sub_j = Sub_x Xor Sub_crc8
                                    Sub_j = 1 And Sub_j
                                    Shift Sub_crc8 , Right , 1
                                    Shift Sub_x , Right , 1
                                    If Sub_j <> 0 Then
                                    Sub_crc8 = Sub_crc8 Xor &B10000111
                                    End If
                  Next
         Next

[Lattice User (Gast)]

Martin Schwaikert schrieb:
> Vielleicht kannst Du mir aber erklären, warum ich die Adresse, sowie die
> Adresse +1 übergeben muss.

Das ist bei I2C (und damit bei SMBUS) eben so.
Man kann bei I2C ein Device entweder zum Schreiben oder zum Lesen 
addressieren, wobei das LSB der Addresse angibt ob gelesen oder 
geschrieben werden soll. Wenn ein Device mehrere Register hat, muss man 
halt vor dem Lesen erst die Registeraddresse schreiben.

http://www.classic.nxp.com/acrobat_download2/literature/9398/39340011.pdf
http://www.nxp.com/documents/user_manual/UM10204.pdf