LTC6811 communicatie werkt niet

Oke, ik heb even een verse blik nodig... Ik ben bezig met een Battery Management System (BMS) op basis van de LTC6811. Een Raspberry Pi babbelt SPI met een LTC6820. Deze zet de gebruikelijke SPI signalen om naar een isoSPI signaal dat via een signaaltransformator naar de LTC6811 gaat (deze kan dat eventueel weer doorgeven aan andere LTC6811's als ik meer dan 12 cellen heb.

Om een lang verhaal kort te maken: De LTC6820 reageert zoals verwacht. De SPI signaleen gaan er in en de isoSPI signalen komen er uit met je juiste fase, voldoende amplitude en lengtes rond de waardes die kloppen volgens de datasheet). Beginnend met de wakeuppuls.

De LTC6811 reageert op de wakeuppuls. Hij schakelt zijn DRIVE pin in zodat een transistor 5v gaat produceren waarmee de 6811 voeding krijgt. Op de Ibias pin komt 2V te staan voor de voeding van het isoSPI drivercircuit en ook als voeding voor een spanningsdeler die het schakelniveau voor de comperator die de isoSPI signalen ontvangt.

Afgezien van dat reageert de LTC6811 verder helemaal niet. Ik stuur:
CMD 0b0000000000000010)
PEC 0b10101100001010)
Dus in bytevorm en volgorde van versturen: 0x00, 0x02, 0x2B, 0x0A, (met hierna nog 8 bytes aan 0'en om de te ontvangen gegevens binnen te halen)

Dit zou het commando en bijbehorende pec moeten zijn waarmee ik registergroep A zou moeten terugkrijgen. De MISO blijft echter continue 1.
Als ik de isoSPI op de scope bekijk die ik de pulsen van de 6820 netjes vertrekken maar de 6811 reageert totaal niet. (terwijl hij dus wel zn voeding en Ibias aan zet. Dus het wakeupsignaal komt echt 100% zeker binnen).

Ik heb gecontroleerd:

  • De polariteit van het isoSPI signaal zowel voor als achter de scheidingstrafo.
  • De amplitude van het isoSPI signaal voor en achter de trafo.
  • De lengte van zowel de eerste als de tweede helft van de golf (differentieel signaal, fase bepaald of het een 1 of een 0 is).
  • Aansluitingen (waardes van weerstandsdeler, beide kanten zijn aangesloten en de aftakking komt ook tot op de pin van de chip, geen kortsluiting tussen de akelig kleine pinnen, etc)
  • Andere commando's waarmee ik gegevens terug zou moeten krijgen (zelfde verhaal)
  • De tijd tussen het laag maken van CS (wat de wakeuppuls stuurt) en het daadwerkelijk communiceren, dit heb ik de minimale wakeuptime van 200us, de maximale van 400us, de gemiddelde van 300us, en zelfs 1000us geprobeerd. Geen enkel verschil. Zelfs twee wakeup pulsen achter elkaar... same story.
  • De volgorde van de bytes die ik richting de chips stuur.
  • De PEC (in de datasheet staat de berekening en 1 voorbeeld, online heb ik nog een ander voorbeeld gevonden, in beide gevallen komen mijn uitkomst overeen. Dus dat zou moeten kloppen.

Het solderen heeft even moeite gekost, dus ik kan me voorstellen dat ik de chip simpelweg geroosterd heb. Maar het vreemde vind ik dat de chip overduidelijk reageert. Dus aansluitingen en signaal zou alleen op basis daarvan al goed moeten zijn. Maar toch krijg ik geen enkel signaal terug.

Ik ben even door m'n ideeen heen... Heeft iemand de gouden tip voor mij?

Alvast bedankt!
Daan

Ik zou met een scope of logic analyser naar de bus tussen de 6820 en 6811 kijken. Ik ken die LTC6820 niet (wel een leuk chipje), en ik begrijp nog niet helemaal hoe dat een clock en data in beide richtingen over één paartje gestuurd wordt. Persoonlijk zou ik gewoon 4 snelle optocouplers (of andere isolators die hetzelfde werken) hebben gebruikt, maar dat werkt niet voor lange afstanden en daarvoor heb je meer draden nodig, dus als dit werkt is het wel een mooie oplossing.

Kun je de communicatie met de 6811 testen zonder dat setje 6820's er tussen?

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Hi Sparky,
Dank voor je reactie!

Er zit geen setje 6820's tussen, de 6820 hangt direct tussen rPi en 6811. Het is Rpi(SPI)>(SPI)6820(isoSPI)>(isoSPI)6811. De 6811 heeft zelf ingangen voor de isoSPI, afhankelijk van een pin aan vdd of aan vss kan je de 6811 normale SPI aanbieden óf (zoals in mijn geval) de isoSPI bus.

Het is inderdaad een mooi kunstje. En eigenlijk vrij eenvoudig (na uren door de datasheet gespit te hebben en het tig keer op een scope gezien te hebben ;)). Op de eerste flank van de klok is MOSI geldig. Als dat een 0 is gaat de isoSPI eerst omlaag voor 50ns en dan omhoog voor 50ns. Als het een 1 is is het andersom. Op de tweede flank van de klok stuurt de 6811 een pulsje terug volgens de zelfde regels.

Ik kan dus met zekerheid zeggen dat de 6811 het signaal goed binnenkrijgt (en daar dus ook op reageert door zijn eigen voeding aan te zetten en het Ibias pinnetje hoog te maken voor voeding en de referentie voor het ontvangen van de isoSPI signalen en daarop te reageren.). Na de scheidingstrafo zie ik de pulsen netjes voorbij komen met de (vrijwel) zelfde amplitude en timing en de juiste fase. Maar op de tweede flank van de klok gebeurt er niks... Dus hij ontvangt op zn minst de wakeuppuls en reageert daarop. Maar het lijkt alsof hij de communicatie daarna compleet negeert. Hierom heb ik eerst anderhalve avond liggen klooien met de PEC. Als deze niet klopt negeert de 6811 het volledig. Maar met code die nét niet kopieren/plakken uit de datasheet komt én met twee verschillende inputs het juiste antwoord geven lijkt het me niet dat dat nog een probleem kan zijn...

Ik had de datasheet van de LTC6820 nog niet bekeken, nu begrijp ik het, en ook waarom het debuggen moeilijk is.

Ik heb nooit begrepen waarom de fabrikanten geen volledig bericht inclusief correcte checksum in de datasheet zetten, dat zou het debuggen van zulke problemen zoveel simpeler maken!

Als ik de datasheet goed begrijp, zou je die LTC6820 ook via een normale SPI bus aan kunnen sluiten, toch? Dat zou je op die manier de SPI communicatie en checksum berekening kunnen controleren?

Heb je de mode van je SPI bus wel goed staan (clock polariteit en fase)?

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

In de LTC6811 datasheet staat een voorbeeldberekening van de PEC met een uitkomst. Voor zover ik kan vinden moet ik ongeacht of ik direct met SPI of via isoSPI (via een 6820 dus) exact dezelfde format aanhouden. Maar inderdaad, een tweede voorbeeld had heel veel zoekwerk bespaard!

De LTC6820 hangt aan de normale SPI bus (CS, CLK, MISO, MOSI bedoel ik dan). Dat is juist de chip die de vertaling maakt naar de isoSPI signalen en het mogelijk maakt omdat door een trafotje heen te halen om de hele accu te isoleren van de rPi en overige besturing.

De mode lijkt te kloppen. Nog buiten het feit dat ik dat natuurlijk ongeveer 200 keer gecontroleerd heb...
POL en PHA zijn beide 0. dwz, die hangen rechtstreeks aan de GND pin
POL = 0 betekend dat de SCLK in rust laag is. Op de scope kan ik duidelijk zien dat dit inderdaad het geval is
PHA = 0 betekend dat MISO en MOSI geldig zijn op de eerste (opkomende dus) flank van de CLK. En de data verschoven word op de tweede flank van de CLK. Wederom: op de scope duidelijk te zien dat de rPi dat allemaal goed doet.

En bovenal: De 6820 werkt ook naar behoren. In zoverre: ik stuur SPI signalen naar de 6820 en die komen op de isoSPI bus terrecht. De hand vol pulsen die ik gecontroleerd heb waren in de juiste polariteit (+1 of -1 puls, Respectievelijk een 1 of een 0) en ook met de juiste timing, etc.

De windingen van de trafo's zijn ook juist dus de pulsen komen met de juiste polariteit weer uit de trafo aan de kant van de LTC6811. Sterker nog: de LTC6811 reageert ook! (zet zijn eigen spanningsregeling aan en verzorgt de voeding voor het drivercircuit zodat hij kan reageren op de isoSPI bus). Maar dat is ook alles wat er gebeurt. Hij babbelt niet terug op de isoSPI bus zoals met dat commando eigenlijk zou moeten gebeuren...

Ik heb het opgelost!

In de eerste instantie lag het hoogstwaarschijnlijk aan software (berekening van PEC zat bij de eerste pogingen nog een fout in, en de volgorde van de bytes in het telegram zat niet goed).

Omdat het niet werkte heb ik de scope er aan gehangen, tijdens het troubleshooten heb ik bovenstaande problemen opgelost waardoor de boel inprenciepe zou werken... ware het niet dat de scope er aan hing.

Ik had 1 kant van het geisoleerde signaal aan de scopeground gehangen (zou moeten kunnen volgens internet). Maar zodra ik die los haalde werkte het meteen. Twee scopekanalen gebruiken en dan met math van elkaar af trekken werkt wel.