Problem med I2C kommunikation till en Fuelgauge krets

[RobertSvalmark]

Hej.
Jag håller på att bygga ett laddkort till li-ion batterier som exjobb. Jag är klar med konstuktionen och ska nu prova kortet. För att kommunicera med kortet så har jag skaffat en USB-I2C modul så jag kan skicka kod direkt från datorn och in på kortet. Programmet jag skickar koden i är ett hemmasnickrat program, som fungerar ungefär som hyperterminalen. Jag behöver bara skriva hexkoderna och trycka på transmit (tex: $5A $01, då får jag tillbaka lite info om själva USB-I2C modulen).

Problemet jag har är att jag inte får något svar från mitt kort. Jag vet inte vad felet kan vara, det kan ju vara något fel på kortet. Men eftersom jag inte är säker på hur jag ska skriva för att få nått svar så tror jag det är där felet ligger.

Så jag tänkte fråga ifall det fanns någon här som är väldigt duktig på I2C kommunikation som kan hjälpa mig.

Kretsen på kortet som jag vill kommunicera med heter BQ27510-g2
datablad: http://www.ti.com/lit/ds/symlink/bq27510-g2.pdf

USB-I2C modulens datablad: http://www.robot-electronics.co.uk/htm/usb_iss_tech.htm
Mer info om just I2C kommunicationen: http://www.robot-electronics.co.uk/htm/ ... c_tech.htm

Har själv aldrig tidigare sysslat med I2C, har inte så jättemycket erfarenhet i huvud taget heller, så all hjälp uppskattas.

Tack på förhand
//Robert Svalmark

[niklo]

det är nog bra om du kan lägga upp schema på kortet så vi vet hur det är kopplat!

[swesysmgr]

Jag hade försökt låna ett digitalt oscilloskop eller någon form av enkel analysator typ Saleae. Då kan du tjuvkika på I2C-kommunikationen och se om TI-kretsen svarar med ett ACK eller NAK när du skickar eller kommando eller om du inte får något svar alls.

Här är ett exempel på hur det kan se ut:

Adress+ack.png

[RobertSvalmark]

Schema på kortet får jag nog inte lägga upp eftersom jag gör detta åt ett företag, men just den delen som jag har problem med liknar referensshemat i databladet.
Men det är inga direkta konstigheter, jag har kopplat I2Cn direkt på fuelgauge-kretsen.

Jag har ett oscilloskop inkopplat som jag kan se vad som händer. Programmet som jag skickar med kan jag även läsa av med, och jag får svar men jag får samma svar oavsett om jag har kortet inkopplat eller inte. Antingen så svarar den $FF $00 (då ska de tydligen ha gått bra) eller så svarar den $00 $01 (det ska betyda att den inte får nått svar) eller så svarar den $00 $05 (Det vet jag inte vad det betyder)

Hittade ett till datablad som visade lite exempel på hur man ska göra.
http://www.ti.com/lit/an/slua467a/slua467a.pdf

Problemet tror jag ligger i att jag måste skriva på ett speciellt sätt när jag använder mig av den där USB-I2C modulen. Jag förstår bara inte hur jag ska kombinera dem.

[swesysmgr]

Kan du verifiera med scopet att I2C kommunikationen är OK så koppla upp ett terminalprogram mot USB-I2C adapterns virtuella COM-port och skicka in sekvensen för avläsning av firmwareversion i TI-kretsen, figur 2 och 3 den senaste PDF-filen.

Det är noga med att skriva in allt i exakt rätt ordning, först kedjan av kommandon för initialisering av läsning, därefter själva läsningen.

[Micke_s]

Testa även att scanna av alla addresser och se vad du får ack på.
Det är inte så enkelt att addressen räknas som 7bitar utan read/write biten eller räknas som 8bitar. (faktor 2 mellan)

[JohnGalt]

"Det är inte så enkelt att addressen räknas som 7bitar utan read/write biten eller räknas som 8bitar"

Ja, ang det där är det väldigt vanligt med olika uppfattningar.

En del säger att adressen är t ex 0x40 (skriv) och 0x41 (läs), medan andra säger att adressen är 0x20, både för skriv och läs. Allt beroende på om man ser R/W som A0 eller ej.
Det finns säkert något som är rätt, men båda sätten används så det gäller att veta vad som menas.

[ToPNoTCH]

Du har begripit att I2C'n vill ha pullups ?

[Micke_s]

själv så tycker jag r/w är A0. Finns enheter som bara går skriva till t.ex.

[RobertSvalmark]

Kan du verifiera med scopet att I2C kommunikationen är OK så koppla upp ett terminalprogram mot USB-I2C adapterns virtuella COM-port och skicka in sekvensen för avläsning av firmwareversion i TI-kretsen, figur 2 och 3 den senaste PDF-filen.

Det är noga med att skriva in allt i exakt rätt ordning, först kedjan av kommandon för initialisering av läsning, därefter själva läsningen.

Hur ska jag skriva kedjan då? Ska jag skriva nått mellan varje kod så att den väntar på ACK?
Jag bör skriva något innan också så att USB-I2C modulen vet att jag ska skicka ut, det finns massor olika alternativ.
Det jag fått bäst resultat hittils ifrån är om jag skriver $57 först (I2C_DIRECT-mode), men vet inte om det är det alternativet jag ska använda mig av.
Har provat att skicka: $57 $01 $AA (I2Cdirect, startbit, skrivaddressen på fuelgaugen), då får jag NACK tillbaka och felkod $01 (Device error No ACK from device).
Jag har provat att byta ut $AA mot några andra adresser och då får jag svaret NACK med felkod $05 (det står inte i databladet vad den felkoden betyder)
Har även provad att skriva en längre kedja men då får jag inget svar alls.


Det sitter pullupp-motstånd på USB-I2C modulen, det stod att det räkte med att koppla in den rakt på.
Fuelgaugens skrivadress är $AA, läsadressen är $AB

[TomasL]

Dessa Fuel-Gauge kretsar är väl egentligen SM-Bus, i princip kompatibla med I2C men inte helt, det är inte säkert att din USB/I2C adapter kan hantera det.

Vill minnas att spänningsnivåerna är 3V istället för I2C som är specad för 5 Volt, plus lite annat.

Sedan kan det ju vara bra att läsa originalstandarden för I2C, Microchip har ett antal mycket bra papper om I2C.
Normalt sett är I2C tämligen problemfritt, så länge man inte försöker implementera en helt mjukvarubaserad slav, helt utan HW-stöd.
Du skickar i princip Adress, Kommando och data i en enda sändning, väntar på ett ACK.

[MiaM]

Orginalstandarden för I2C är väl iofs Philips som tagit fram, så det är väl de som har orginaldokumenten?

[cyr]

Hur ska jag skriva kedjan då? Ska jag skriva nått mellan varje kod så att den väntar på ACK?
Jag bör skriva något innan också så att USB-I2C modulen vet att jag ska skicka ut, det finns massor olika alternativ.
Det jag fått bäst resultat hittils ifrån är om jag skriver $57 först (I2C_DIRECT-mode), men vet inte om det är det alternativet jag ska använda mig av.
Har provat att skicka: $57 $01 $AA (I2Cdirect, startbit, skrivaddressen på fuelgaugen), då får jag NACK tillbaka och felkod $01 (Device error No ACK from device).
Jag har provat att byta ut $AA mot några andra adresser och då får jag svaret NACK med felkod $05 (det står inte i databladet vad den felkoden betyder)
Har även provad att skriva en längre kedja men då får jag inget svar alls.


Det sitter pullupp-motstånd på USB-I2C modulen, det stod att det räkte med att koppla in den rakt på.
Fuelgaugens skrivadress är $AA, läsadressen är $AB

Tror du borde göra något sånt här:

$57 $01 $32 $AA <cmd> <data> $03 (start, skriv 3, addr, cmd, data, stop) för att skriva ett "kommando" med en byte data
$57 $01 $31 $AA <cmd> $02 $30 $AB $04 $20 $03 (start, skriv 2, addr, cmd, restart, skriv 1, addr, nack, läs 1, stop) för att läsa en byte.

Det är iaf hur jag får ihop det med sidan 31 i databladet och beskrivningen på i2c-kommandona till din USB-grunka...

Sen hur det funkar med "kommandon" på den här kretsen (SMBus?) förstår jag mig inte riktigt på, inte riktigt det vanliga register-tänket som de flesta vanliga I2C-saker kör med.

[RobertSvalmark]

Tack för alla svar, jag har lite att prova nu. Jag har inte tillgång till att prova det idag, men imorgon ska jag labba lite.

SMBus vet jag inte så mycket om, men tror jag stötte på det när jag kollade på andra fuelgaugekretsar. Dock tror jag inte denna användeer sig av det. Det står ingenting om SMBus i databladet iaf.

[RobertSvalmark]

Har nu testat lite till och hittade ett stort fel, ett rätt klantigt fel av mig. Jag hade missat att dra strömförsörjning till kretsen, så det var inte så konstigt att jag alltid fick samma svar oavsett om kortet var inkopplat eller inte.
Men jag har fortfarande inte kommit på hur jag ska skriva för att få den att göra som jag vill, jag har endast lyckats med att skriva en byte till den och få den svara med ACK. Skriver jag 2 eller fler byte till den så skriver den första, ger ACK tillbaka sen skriver den den andra byten, sen svarar den inte längre.
Har lite att prova nu.