LTC6813 über isoSPI mit LTC6820 und STM32

[Fredo (Gast)]

Moin zusammen,

Ich bin gerade daran ein BMS zu realisieren und zwar mit dem LTC6813 von 
Analog Devices als Slave Baustein und einem STM32 als Master. Die 
Datenübertragung erfolgt mittel isoSPI und Masterseitig sorgt der 
LTC6820 für die Umwandlung zwischen SPI und isoSPI.

Leider habe ich folgendes Probelem:
Der Master sendet zwar Daten, der Slave antwortet jedoch nicht.
Die Daten die gesendet werden wurden mit dem Oszillieren überprüft.
Hat irgendjemand schonmal ähnliche Probleme gehabt?
Meine Vermutung ist das der LTC6813 nicht aus dem Sleep Zustand 
aufwacht...

Vielen Dank schonmal

[Darth Moan (Gast)]

Moin,
wie sieht denn dein Oszi Bild aus? Also hinter dem 6820.
Der geht nämlich auch in den Idle Mode nach x ms. Dann braucht er
ein paar us um in den Transfer Mode zu gehen. Wenn also der 6820
im Idle war muss das CS einn paar us früher kommen als die Daten
anfangen dürfen, rausgeclockt zu werden.
Der 6813 hat dann auch wieder einen Idle und Sleep Mode. Deren Wakeup
Prozeduren sind aber recht gut im Manual beschrieben.
Wenn die Empfindlichkeit über die beiden Widerstande Rb1 und Rb2 zu
niedrig ist, kann das bei schlechtem Kabel zu Terminierung dazu führen
dass der 6813 die Pulse teilweise nicht erkennt. Oder antworted dieser
und der 6820 erkennt sie nicht?

[Fredo (Gast)]

Also die Leitung ist beidseitig mit 120 Ohm terminiert und beidseitig 
befinden sich Symmetrierübertrager mit CMC. Vor und nach diesen ist das 
Signal aber nahezu identisch. Anbei mal eine Aufnahme wo ich 0x20 
übertragen habe.

[Darth Moan (Gast)]

Moin,
Die Pulse sehen gut aus CS und etwas später die Daten.
Was genau schickst du denn? Also damit du was bekommst, musst du ja
z.B. ein RDCFGA schicken (0x00 0x02 0x2B 0x0A + 8 bytes Dummy Daten
zum lesen). Erst wenn die Antwort 0 bits enthält geht ein Puls
zurück. Also erst ab Bit 33 kann ein Puls zurücklaufen.
Hast du nur einen 6813 dran oder eine Daisy Chain?

[Fredo (Gast)]

Moin,

Ich schicke
0x00
0x02
0x2B
0x0A
0x00
Und danach ziehe ich den CS wieder hoch.
Komischerweise sendet der Master aber nur 19 Pulse.
Im moment habe ich nur einen 6813 dran.

[Darth Moan (Gast)]

Hmm?
Das sieht aber seltsam aus. Also der lange Puls nach den 19 kurzen
Datenpulsen ist ein CS rising edge. Das sendet der 6820 aber
eigentlich nicht von alleine. Wie sieht denn die STM SPI zu der Zeit
aus?
Also wartest du bis entweder das Buy Flag zeigt, das die Daten alle
raus sind, oder bis alle RX Daten empfangen sind?
Sowas hatte ich am Anfang, als ich nicht auf die Empfangsdaten
gewartet hatte und dabei nicht auf das TX Busy Flag geachtet habe.
Da hab ich CS viel zu früh hoch gezogen.
Aber wenn du das Register lesen willst must du ja CMD + PEC + 8 Bytes
Dummy Daten schicken, also 12Byte insgesammt.

[Fredo (Gast)]

Also ich schicke die Dummy Daten als SPI_Receive damit ich die Variablen 
auslesen kann. Komischerweise werden immer noch nicht alle Daten 
übertragen.

Hier mal der Codeausschnitt:

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_SET );
     HAL_Delay(10);

      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_RESET );



      HAL_SPI_Transmit(&hspi2, spiData0, 1, 0);
      HAL_SPI_Transmit(&hspi2, spiData1, 1, 0);
      HAL_SPI_Transmit(&hspi2, spiData2, 1, 0);
      HAL_SPI_Transmit(&hspi2, spiData3, 1, 0);

      HAL_SPI_Receive(&hspi2, &slaveData0, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData1, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData2, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData3, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData4, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData5, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData6, 1, 0);
      HAL_SPI_Receive(&hspi2, &slaveData7, 1, 0);

      while(SPI2->SR & SPI_SR_BSY)
      ;
      HAL_Delay(50);
      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_SET );
      HAL_Delay(10);

[Rudolph (Gast)]

Ich habe seit Ende des letzten Jahres eine Platine fertig mit ebenfalls 
dem LTC6813 und einem LTC6820.
Nur konnte ich da noch gar nichts dran beobachten, weil wir den LTC6813 
immer noch nicht in die Finger bekommen haben, nicht mal die Muster von 
Analog wurden bisher überhaupt verschickt.
Gibt es die Dinger jetzt schon irgendwo?

[Fredo (Gast)]

Wir haben ein Evaluation Board bekommen zum testen.
Die Chips haben wohl noch 1 Jahr Lieferzeit...

[Rudolph (Gast)]

Ugh. :-)
Ende letzten Jahres war es noch Januar, jetzt hoffen wir gerade auf kurz 
nach Ostern, oder dass die Muster doch noch vorher raus gehen.

Nur am Rande, ich habe auf unsere Platine einen ATSAMC21E18A gepackt und 
mich für Isolation mit Kondensatoren entschieden.
Die Zell Daten sollen praktisch auf der anderen Seite des Controllers 
gleich wieder auf dem CAN raus fallen.

[Fredo (Gast)]

Genau das gleiche soll unser Master auch machen, bzw. nur die relevanten 
Daten sollen auf den CAN.

Leider habe ich Probleme mit dem auslesen der Daten.
Wie habt ihr das gelöst?

[Dr. Sommer (Gast)]

Sicher dass die gesendete CRC richtig ist? Wenn nicht, kommt keine 
Antwort...

Es gibt von LT so ein Arduino Board mit LTC6820. Damit kann man sehr 
leicht korrekte Anfragen senden. Das ist gut um Fehler zu suchen.

[Fredo (Gast)]

Ich lese das RDCFGA Register aus wobei die CRC sicher stimmt. Aber 
sobald ich die SPI Signale einlesen sehe ich auf dem isoSPI Leitung nur 
'1'.
Gelb ist CLK
Grün MOSI
Blau die isoSPI Leitung, wobei nach 4 Bytes immer '1' kommen.

[Fredo (Gast)]

Fredo schrieb:
> Ich lese das RDCFGA Register aus wobei die CRC sicher stimmt. Aber
> sobald ich die SPI Signale einlesen sehe ich auf dem isoSPI Leitung nur
> '1'.
> Gelb ist CLK
> Grün MOSI
> Blau die isoSPI Leitung, wobei nach 4 Bytes immer '1' kommen.

Ups das war wohl das falsche Bild...

[Rudolph (Gast)]

Fredo schrieb:
> Wie habt ihr das gelöst?

Na, noch gar nicht, wir haben keinen LTC6813, das Board liegt seit zwei 
Monaten praktisch nur so rum, ein Evalboard zu kaufen schien nicht 
sinnvoll zu sein...

[Darth Moan (Gast)]

Moin,

Fredo schrieb:
> Also ich schicke die Dummy Daten als SPI_Receive damit ich die Variablen
> auslesen kann. Komischerweise werden immer noch nicht alle Daten
> übertragen.

Aber warum um alles in der welt macht man denn sowas?
Der Master muss so oder so die Clocks generieren, also schiebe ich in
einem Rutsch alle Daten raus. Dafür hat die SPI doch MOSI und MISO.
Die Dummy daten bekommen gleich ein entsprechendes Zählpattern verpasst,
damit man im Oszi Bild sofort sieht, wo man in der Botschaft ist und
keine Pulse zählen muss. OK, ich hab ne Daisy Chain mit 10 von denen.
Naja der 6813 wird die zahl der ICs in der Daisy Chain reduzieren.
Nun kenne ich die besonderheiten der HAL Funtionen nicht, weil ich die
drei Register selber fülle und immer die volle Botschft per DMA durch
knüpple. Die SPI betreibe ich auch im 16Bit modus, da meine Botschaften
immer eine gerade Anzahl Bytes haben.

Tja die 6813 sind wohl nicht leicht zu kriegen, aber fuer die 
allgenmeine
SPI kommunikation kannst du doch einfach einen anderen nehmen. Ich habe
6804er boards. Die koennen nur 12 Zellen, aber ansonsten ist alles
so gut wie gleich. OK ein oder zwei Register fehlen, aber wie die SPI
funktioniert, wie ein Messzyklus funktioniert, wie die Selbsttests
funktionieren ist doch alles gleich. Mehr als einen einzelnen 6813 hab
ich auch nicht, aber die 6804 sollten doch verfügbar sein, oder?

[Darth Moan (Gast)]

Moin,

Fredo schrieb:
> Ups das war wohl das falsche Bild...

Äh felht da nicht das MISO signal?
Oder hast du MISO und MOSI mit ner Diode zusammen geknotet?

[Darth Moan (Gast)]

Moin nochmal,

Also im xcope_9.png ist ja zu sehen, dass gar keine Pulse zurück laufen.
Sind vielleicht die Adern vertauscht? Dann sieht der 6813 die Pulse
invertiert, also CS risig edge, Dataclocks, CS falling edge. Dann dürfte
er nicht antworten, da er wärend CS low keine Daten zu sehen glaubt.
Wenn er dagegen noch nicht aufgewacht war, dann würde an seinem Daisy
Chain Ausgang kein korrektes Kommando + PEC zu sehen sein. Wenn er Ready
ist, sollte ein Puls, egal ob CS oder daten, mit nur sehr kurzer
Verzögerung am IPB/IMB raus kommen. Das könnte man einfach messen. Hab
jetzt nicht nachgeschaut, aber ich glaube das war um 180ns delay von
IPA/IMA zu IPB/IMB.

Also nicht falsch verstehen, die 6804er hab ich zuerst benutzt um 
überhaupt
mit einem Chip über isoSPI zu kommunizieren.
Dann die Botschaftsdefinitionen angepasst und den 6813er dran. Klappte
ohne grosse Probleme. Mit den 6804ern kann man auch alle Daisy Chain
Effekte mal in echt ausprobieren.

Wenn ihr Problemen mit dem Lesen habt, kommen dann isoSPI Pulse vom 6813
zurück und werden nicht erkannt, oder kommen gar keine Pulse zurück?

[Rudolph (Gast)]

Darth Moan schrieb:
> Mehr als einen einzelnen 6813 hab
> ich auch nicht, aber die 6804 sollten doch verfügbar sein, oder?

Die LTC6804 sind verfügbar, das hilft nur überhaupt nicht wenn man eine 
Platine hat auf der ein LTC6813 fehlt.
Wenn wir im November gewusst hätten, dass sich das bis mindestens nach 
Ostern hin ziehen wird, dann wären wir da auch anders ran gegangen - 
oder hätten gleich einen anderen Chip von einem anderen Hersteller 
benutzt.

Nun ja, das wird schon noch.

[Darth Moan (Gast)]

Rudolph schrieb:
> Die LTC6804 sind verfügbar, das hilft nur überhaupt nicht wenn man eine
> Platine hat auf der ein LTC6813 fehlt.

OK, das stimmt.
Aber mit Fädeldrähten von den IPA/IPB Pads müsste man auf ein Demo
board gehen können. Dann kann man wenigstens irgendwas probieren.
Gibt es denn 6813er Demo Boards zu kriegen?
Natürlich muesste man aufpassen, dass der fehlende Chip auf der Platine
keine weiteren Probleme verursacht, also nix abfackelt und den
Terminierungswiderstand runter nehmen.
Also ich hab hier immer noch meine allerersten Drahtverhaue von Nucleo
Board zu Lochraster zu LTC Demo Board zum Vergleich.
Die "richtige" HW hat ja ewig lange gebraucht, bis ich die auch nur mal
gesehen habe.

[Rudolph (Gast)]

Es gibt das DC2350A für gut 160 Euro.
Nur wenn die Lieferdaten für den LTC6813 gestimmt hätten, dann hätten 
wir das nach rund vier Wochen schon wieder weg legen können.
Um drei bis vier Monate zu überbrücken hätten wir uns das im Januar 
gegönnt, jetzt aber nicht mehr.

[Darth Moan (Gast)]

Rudolph schrieb:
> Um drei bis vier Monate zu überbrücken hätten wir uns das im Januar
> gegönnt, jetzt aber nicht mehr.

Das kann ich irgendwo verstehen.

Auf der anderen Seite sind im letzten Jahr so viele unglaubliche Dinge
passiert, da würde ich die 160 Euronen unter Risikoabsicherung 
verbuchen.
Allerdings hab ich ja auch keine Ahnung, wie sicher jetzt euer 
Ostertermin
ist.


Fredo,
konntest du mal prüfen ob die Pulse mit geringer Verzögerung an IPB/IMB
wieder rauskommen?
Wenn ja, war der 6813 jedenfalls nicht im Sleep Mode.
Ich hab ja ne Daisy Chain und daher "Waking a Daisy Chain—Method 2"
umgesetzt. Danach lasse ich nie mehr als 1ms vergehen ohne isoSPI
Kommunikation. Als Dummy Traffic lese ich die Config A/B register
oder PLADC.

[Fredo (Gast)]

Darth Moan schrieb:
> konntest du mal prüfen ob die Pulse mit geringer Verzögerung an IPB/IMB
> wieder rauskommen?

Ich habe das so eben getestet und habe keine Daten am isoSPI Port B 
feststellen können.
Bedeutet das, dass sich der Chip immer noch im sleep Modus befindet?

Ich nutze eigentlich auch die Methode zwei um den Chip aufzuwecken, 
indem ich alle 10ms RDCVA sende.

Hier ist nochmal mein aktuellster Code vlt findet ihr einen Fehler:

          spiData0[0]=0x00;// configuration register group A RDCVA
    spiData1[0]=0x02;// configuration register group A RDCVA
    spiData2[0]=0x2B;// PEC
    spiData3[0]=0x0A;// PEC

     HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_SET );    // CS 1
     HAL_Delay(10);                                         // 10 ms 
delay


while(1)
{


      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_RESET );    // CS 0



      HAL_SPI_Transmit(&hspi2, spiData0, 1, 1);//Transmit spiData0 on 
spi2
      HAL_SPI_Transmit(&hspi2, spiData1, 1, 1);//mit 1 ms pause nach

      HAL_SPI_Transmit(&hspi2, spiData2, 1, 1);//Übertragung
      HAL_SPI_Transmit(&hspi2, spiData3, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData0, 1, 1);// Empfangen mit 1ms

      HAL_SPI_Receive(&hspi2, &slaveData1, 1, 1);//Pause danach

      HAL_SPI_Receive(&hspi2, &slaveData2, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData3, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData4, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData5, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData6, 1, 1);
      HAL_SPI_Receive(&hspi2, &slaveData7, 1, 1);

      while(SPI2->SR & SPI_SR_BSY)    // wait till SPI function finishes
      ;
      HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9,GPIO_PIN_SET );    // CS 1
      HAL_Delay(10);      // 10 ms delay
}//end while

[Fredo (Gast)]

update: ich kriege ein Signal zwischen IPB und IMB, das hab ich aufgrund 
zu kleinen Zooms übersehen.
Wenn ich nicht Falsch messe ist das aber ein Stop- anstatt eines 
Start-Signals

Bild von Oszi und Messpunkten im Anhang

[Darth Moan (Gast)]

Moin,

Fredo schrieb:
> Ich habe das so eben getestet und habe keine Daten am isoSPI Port B
> feststellen können.
> Bedeutet das, dass sich der Chip immer noch im sleep Modus befindet?

Es scheint fast so. Wobei er aber erst nach typ. 2s in den Sleep gehen
sollte. Allerdings hat das SPI Interface seinen eigenen IDLE State und
nach typ. 5.5ms geht das Interface in den IDLE Mode. Daraus kann er
"aufgeweckt" werden wenn nach CS nach low 10us wartet bevor die Daten
geclockt werden. Allerdings sorge ich dafür, dass er garnicht erst in
den IDLE Mode geht indem ich alle 1ms ein Dummy PLADC Kommando schicke,
wenn sonst nichts gesendet werden würde.

Hmm, die 3us Delay würden dazu passen, wenn er nicht im Sleep sondern
im Idle Mode war. Aber dass der Puls eine CS nach high ist, erklärt
sich mir nicht. Auch sollten nach spätestens 10us auch alle Datenpulse
direkt hinten wieder rauskommen.

[Darth Moan (Gast)]

Sind die Adern am eingang wirklich nicht verdreht?
Oder hast du für beides EVAL-Boards verwendet?
Sonst würde ich einfach mal versuchen die IPA/IMA zu verdrehen.

Obwohl ich gerade lese:
The LTC6813-1 sends a long +1 pulse on Port B after it is ready to 
communicate.
Und in deinem Oszi Bild ist ein langer +1 Puls (lila).
Also könnte es doch korrekt verdrahtet sein. Er erkennt Aktivität auf
dem Port A und sendet dann auf B den WAKE Pulse (long +1).
Aber warum kommen die Datenpulse nicht durch?

Mein Wake Pulse ist nur ein CS low, 15us warten, CS high. Dann 420us
warten und nochmal, für jeden Chip in der Daisy Chain. Aber du hast
ja nur einen, also sollte das doch so funktionieren, oder?

Könntest du mal probieren, vor der Botschft zusätzlich ein CS low,
10us warten, CS high, 20us warten einzubauen?
Ich kann erst wieder Montag probieren. Vielleicht will er nach dem Wake
Pulse erst ein CS low sehen, bevor er die Daten annimmt. Kann ich jetzt
aber nicht prüfen.

[Darth Moan (Gast)]

Wobei mir gerade einfällt, wenn beim 6820 der EN pin nicht auf high
gezogen ist, geht dieser auch nach 5.xx ms in den Idle mode. Dann kann
schon was an Pulsen verloren gehen. Aber die Oszi Bilder sehen
diesbezüglich gut aus. Nur so der Vollständigkeit halber.
Steuerst du den per Port Pin, oder ist der nach gnd/vcc fest verdrahtet?
Ich meine bei 10ms Delay zwischen den Messages müsste der sonst in
den Idle Mode gehen.

[Fredo (Gast)]

Darth Moan schrieb:
> Könntest du mal probieren, vor der Botschft zusätzlich ein CS low,
> 10us warten, CS high, 20us warten einzubauen?
> Ich kann erst wieder Montag probieren. Vielleicht will er nach dem Wake
> Pulse erst ein CS low sehen, bevor er die Daten annimmt. Kann ich jetzt
> aber nicht prüfen.

Vielen Dank für die Ausführliche Antwort, ich werde denk ich am Montag 
meine Tests fortsetzen und kann das ausprobieren.
Ich habe auch noch ein weiteres Evaluation Board angeschlossen, dieses 
sendet den long +1 pulse zeitversetzt an seinen Ausgang, aber ansonsten 
keine Daten.

von den Leitungen ist nur ein Teil verdrillt (siehe Bild), denkst du das 
beeinflusst die Übertragung?

Das Setup des LTC6820 hab ich auch angehängt, falls es hier 
Unstimmigkeiten mit meinen Code geben könnte. Ich nutze den unteren LTC, 
da oben der SLOW-Pin vergessen wurde

[Darth Moan (Gast)]

Moin,

Fredo schrieb:
> von den Leitungen ist nur ein Teil verdrillt (siehe Bild), denkst du das
> beeinflusst die Übertragung?

Bei den kurzen Leitungen sollte das kein Problem sein. Ich denke, das
beeinflusst eher das Abstrahlverhalten als die Übertragung. Aber auf
dem Schreibtisch sollte das egal sein.

Die Konfiguration sieht soweit genauso aus, ausser das bei mir der EN
auf GND liegt. Daher musste ich mich auch mit dessen Idle Mode
beschäftigen, weil ich den natürlich anfangs vollkommen übersehen
und mir erstmal die Wundertüte aufgesetzt habe.

Und die Widerstände Ribias und Ricmp sind bei mir anders, damit auch
etwas gedämpfte Pulse noch erkannt werden. Ich glaube bei 120Ohm
Terminierung geht das noch, aber da bei mir noch Massnahmen getroffen
wurden die Abstrahlung zu minimieren, sind die Pulse schon etwas 
kleiner.

[Mirco G. (mirco432)]

Hi. Seid ihr schon weiter gekommen? Ich arbeite im Moment auch mit dem 
LTC6813. Ich versuche gerade noch mit ihm über das normale SPI zu 
kommunizieren. Auf MOSi geht auch alles raus wie gewollt aber der IC 
antwortet einfach nicht. CS hab ich einfach die ganze Zeit runter 
gezogen.

Ich habe auch
0x00
0x02
0x2B
0x0A
0x00
gesendet.

dann sende noch Bytes zum auslesen der Daten.

Aber es kommt wie gesagt nix.

Stehe auch ein bisschen auf dem Schlauch wie ich weiter vorgehen soll 
:D.

[Rudolph R. (rudolph)]

Ich glaub ich bin raus.
Die Muster hat Analog jetzt bestätigt, ich weiß nur gerade nicht aus dem 
Kopf ob für November oder Dezember.
Und der Liefertermin von Mouser wird auch immer wieder verschoben.

Zur Belustigung: https://github.com/RudolphRiedel/Cell-Sentinel

[Darth Moan (Gast)]

Moin,

Mirco G. schrieb:
> antwortet einfach nicht. CS hab ich einfach die ganze Zeit runter
> gezogen.

Was meinst du mit "die ganze zeit"?
Der 6813 braucht schon die fallende CS Flanke um ein Kommando zu
erwarten. Wenn Kommando und PEC durch sind, schaltet er in den
"Schieberegister Modus" um Daten rein oder raus zu schieben, je nach
Kommando. Mit der steigenden Flanke ist der Transfer abgeschlossen.
Beim Schreiben werden mit der steigenden Flanke die Daten übernommen,
wenn die PEC stimmt. Erst nach einer neuen fallenden Flanke auf CS
kann ein neues Kommando gesendet werden.
Wenn er kein gültiges Kommando (+PEC) erkennt bleibt MISO immer high.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Mirco G. schrieb:
> CS hab ich einfach die ganze Zeit runter gezogen.
Und was sagt das Datenblatt zu dieser Art von Ansteuerung? Passt das, 
was du direkt an den Pins des Bausteins meesen kannst, zu dem, was 
dieser laut Datenblatt erwartet?

Meine Erfahrung ist nämlich die, dass wenn man sich an die Vorgaben aus 
dem Datenblatt hält, in den allermeisten Fällen die Kommunikation 
funktioniert.