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
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?
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.
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?
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.
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.
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);
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?
Wir haben ein Evaluation Board bekommen zum testen. Die Chips haben wohl noch 1 Jahr Lieferzeit...
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.
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?
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.
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 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...
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...
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?
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?
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?
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.
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.
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.
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.
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
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
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.
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.
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.
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
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.
Beitrag #5854524 wurde vom Autor gelöscht.
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.
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
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.
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.
Bitte 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.