Dataflash vom bq20z65-r1 mit I2C auslesen

[Niklas B. (niklas90)]

Hallo,

wir haben bei unserem Projekt gerade das Problem, dass wir den Dataflash 
des bq20z65-r1 auslesen müssen und es nicht funktioniert.

Die anderen Parameter in den speziellen Registern haben wir leicht 
auslesen können, das war kein Problem. Wir machen das ganze über I2C mit 
einem STM32L1, der die Daten dann weiter per UART an eine weitere 
Peripherie mit einem STM32F4 schickt, der die Daten dann unter anderem 
auf einem Display ausgibt.

Eine grobe Vorstellung, wie man den Dataflash ausliest, steht ja im 
Datasheet des bq20z65-r1, aber wir haben trotzdem noch zusätzlich mal 
mit einem "Saleae"-Logikanalysator die Befehlsabfolge, welche per SMB 
mit der bq-Software erfolgt, mitgelogt. Auf dem Anhang ist das der 
obere, grüne Bereich.


Folgender Ablauf:
- Schreiben der Slaveadresse (0x16)
- dann 0x77 um auf den Dataflash zuzugreifen
- dann 0x0058, aufgeteilt in High- und Lowbyte, das ist die Subclass im 
Dataflash (88)
- Was das 0xC6 bedeuten soll, weiß ich allerdings auch nicht, ist auch 
nirgends dokumentiert.
- Nun schreibt man noch 0x78, was bedeutet, dass man die erste Page, 
also die ersten 32 Byte in der Subclass haben möchte.
- Auslesen mit Read (warum ändert sich hier eigentlich die Adresse auf 
0x17?)

Das scheint für die bq-Software auch gut zu laufen, die bekommt dann die 
32 Bytes in einem kleinen Textfenster angezeigt. Auffällig ist hier das 
erste zurückgesendete Byte (0x20), welches auch in dem Fenster nicht 
angezeigt wird. Wir vermuten es ist nur eine Information wie viele Bytes 
jetzt gesendet werden (32 in dezimal).


Wir wollten das ganze nun mit I2C im STM32L1 nachbilden, das ist der 
untere Bereich im Anhang, unter dem roten Balken.

Komischerweise bekommen wir nur keine Sinnvollen Daten zurück, lediglich 
die letzten 3 Bytes der letzten Übertragung (ich hatte ja erwähnt, dass 
wir die anderen Parameter auch auslesen - das es komischerweise 3 von 2 
sinnvollen Bytes sind, ist ein anderes Thema). Das letzte Byte wird 
dabei 32-3 mal wiederholt, weil meine Readroutine solange liest, bis der 
vorgegebene Bytecounter abgelaufen ist. Wir bekommen schon nicht mal die 
0x20!


Ich sehe beim besten Willen keinen Unterscheid in der Befehlsfolge auf 
dem Logikanalysatorplot, warum funktioniert das nicht?

Hoffentlich könnt ihr mir helfen, ich weiß echt nicht weiter. Wenn ihr 
den Quelltext braucht, den kann ich schicken, aber er ist verdammt 
umfangreich und hat eine Menge #includes, aber ich könnt ja die 
wichtigsten Stellen kopieren. Nur vielleicht liegt der Fehler irgendwo 
im Detail, da würde es vielleicht nix bringen, nur einen Teil zu posten.

Gruß, Niklas

[Niklas B. (niklas90)]

So, ich habe jetzt noch die 2 wichtigsten Quelldateien angehängt.

In der i2c_init.c wird I2C initialisiert und Funktionen zum Lesen und 
Schreiben definiert. Das eigentliche Senden und Empfangen der Bytes wird 
in dem Eventinterrupthandler gemacht, unten auf der Seite habe ich noch 
eine alternative Funktionsweise auskommentiert, mit der Methode komme 
ich auf die gleichen Ergebnisse, bringt also auch nichts.

In der i2c_gase_gauge.c werden die in der init genannten Funktionen 
benutzt um Befehle an den bq20z65-r1 zu senden und die empangenen Bytes 
zu verarbeiten.

[Bla (Gast)]

Niklas Beuster schrieb:
> Hallo,
>
> wir haben bei unserem Projekt gerade das Problem, dass wir den Dataflash
> des bq20z65-r1 auslesen müssen und es nicht funktioniert.
>
> Die anderen Parameter in den speziellen Registern haben wir leicht
> auslesen können, das war kein Problem. Wir machen das ganze über I2C mit
> einem STM32L1, der die Daten dann weiter per UART an eine weitere
> Peripherie mit einem STM32F4 schickt, der die Daten dann unter anderem
> auf einem Display ausgibt.

Vorsicht, der IC verwendet SMBus. Das ist zwar sehr ähnlich zu I2C aber 
eben nicht identisch damit. Ich würde da mal gründlich prüfen ob es an 
einem der kleinen Unterschiede liegen könnte.


> - Auslesen mit Read (warum ändert sich hier eigentlich die Adresse auf
> 0x17?)

Weil eine I2C/SMBus Adresse in diesem Fall 7 Bit (Bits[7:1]) hat und Bit 
0 das R/W-Bit ist (write = 0, read = 1).

[Bla (Gast)]

Oh, und einen Unterschied gibt es mindestens in den beiden 
Logic-Analyzer Screenshots. Nach dem 0x78 kommt im ersten Fall ein 
weiteres START (Repeat START), im zweiten Fall aber ein STOP und dann 
wieder ein START.

Es kann gut sein, dass der Chip das so nicht haben will. Probier mal 
ebenfalls ein Repeat START zu machen.

[Niklas B. (niklas90)]

Ahhrg, danke! Daran hats gelegen >.<