Problem mit I²C-Device

Knut Ballhause schrieb:
> Wie lang ist Dein Bus, wie groß sind die PullUps?

10cm sind die Kabel lang. Die Frequenz liegt bei etwa 300kHz. Pull-Ups 
sind 10k. Das seltsame ist halt nur, dass es immer erstmal geht am 
Anfang, also wenn alles aus dem Power-Up-Status kommt. Dann debugge ich 
immer weiter und dann geht es irgendwann nicht mehr. Dachte natürlich 
immer, es liegt an meiner falschen State-Machine, aber es geht dann ja 
wieder, ohne dass der Code verändert wurde.

Hallo,
es ist ungewöhnlich, dass der ADC den SDA auf L hält. Eigentlich sollte 
das SLAVE-Device nur den SCL auf L halten (Clock-Stretching). Wie 
steuerst Du den IIC an? Benutzt Du aktive Pegel - also treibst Du die 
SCL und die SDA-Leitung? Das wird ja immer wieder gerne gemacht, und 
meist funktioniert das mit vielen SLAVE Devices, kann aber in anderen 
Fällen ganz böse daneben gehen - daher immer nur zwischen Input und 
Output L umschalten. Ich vermute, dass der ADC einen Clock nicht 
erkennt, und daher den letzten SDA-Pegel (könnte sogar der Acknowledge 
sein - der ist nämlich L) festhält.
Ich hatte mal ein ähnliches Problem mit Spike-Clocks - hat mich ca. 3 
Tage für Suche aufgehalten. Erst mit dem Oszi und Impuls-Triggerung habe 
ich den Fehler einkreisen können.
Zu deinen Pull-Ups, die sind auf jeden Fall zu groß (benutze mal 1k8 - 
so wie ich das aus der Spec von Philips rauslese)

Gruß
TK

Knut Ballhause schrieb:
> Das heißt erstmal gar nichts, wenn das Timing an irgendeiner Stelle
> kritisch ist, oder Busfehler nicht korrekt behandelt werden.

Ja gut, OK. Wie das Device Übertragungsfehler behandelt, weiß ich 
natürlich nicht. Was immer klappt, ist das ACK vom Device. Ändere ich 
die Adresse im Adressbyte, so gibt es auch kein ACK. Kein-ACK -> SCL 
high, SDA high (STOP). Dann sollte ja eigentlich alles von vorne 
losgehen.

Knut Ballhause schrieb:
> Mach die PullUps mal kleiner, würde 4k7 nehmen.

Habe ich auch schon probiert, ändert nichts. Davon mal abgesehen, 
verwendet TI in seinen Code-Beispielen ja sogar die internen Pull-Ups 
des uC...und die liegen ja so bei mehren 10k. Trotzdem - habe ich 
bereits probiert.

Knut Ballhause schrieb:
> Liegen SCL und SDA direkt nebeneinander? Übersprechen? Klingeln?

Nee, nicht wirklich. Ich habe noch ein Oszi dran, dachte erst, 
vielleicht ist die Eingangskapazität schon ein Problem, aber ändert auch 
nichts. Es ist sogar so, dass ich manchmal am Punkt der STOP-Bedingung 
bin (schon ausgeführt) und SDA noch auf low ist. Ziehe ich SDA vom MCP 
ab, dann geht es auf high. Der MCP zieht den also runter. Ich habe aber 
auch nirgends im Code stellen, wo z.B. zu wenig Bytes gesendet werden 
o.ä.

Es geht ja auch...theoretisch - nur nicht zuverlässig. Irgendwann kommt 
IMMER folgendes (M)aster / (S)LAVE: (M)START (M)11010001 (S)ACK 
(S)00000001 (M)ACK (S)11111111 (M)ACK (S)11111111 (M)ACK (M)STOP

Gesendet werden soll ja: Adresse, Datenbyte 1, Datenbyte 2, Config-Byte 
mit Status.

Aber es läuft immer auf dieses Muster hinaus.

TK schrieb:
> Wie
> steuerst Du den IIC an? Benutzt Du aktive Pegel - also treibst Du die
> SCL und die SDA-Leitung? Das wird ja immer wieder gerne gemacht, und
> meist funktioniert das mit vielen SLAVE Devices, kann aber in anderen
> Fällen ganz böse daneben gehen - daher immer nur zwischen Input und
> Output L umschalten.

Ich schalte um. Benutze das uC-interne I²C-Feature.

TK schrieb:
> Ich vermute, dass der ADC einen Clock nicht
> erkennt, und daher den letzten SDA-Pegel (könnte sogar der Acknowledge
> sein - der ist nämlich L) festhält.

Aber sein ACK kommt ja nach dem Senden des Adressbytes vom Master. Und 
das letzte Bit ist da High wegen Lesen. Dann kommt ein CLK-Puls und der 
Slave zieht den SDA ordnungsgemäß auf low für das ACK.

TK schrieb:
> Ich hatte mal ein ähnliches Problem mit Spike-Clocks - hat mich ca. 3
> Tage für Suche aufgehalten. Erst mit dem Oszi und Impuls-Triggerung habe
> ich den Fehler einkreisen können.

Da bin ich mittlerweile auch angekommen :-\ Sitze hier auch vorm Oszi 
fest.

TK schrieb:
> benutze mal 1k8

Noch kleiner als 4k7? Bei der niedrigen Frequenz? Ich werds probieren.

Bist Du sicher, dass der Master nach dem letzten Byte ein ACK senden 
muss?
Bei EEPROMs muss hier nämlich ein NACK gesendet werden, damit das Device 
das Ende der Übertragung erkennt. Und dann kommt ein Stopp.

Gruß
TK

TK schrieb:
> Bist Du sicher, dass der Master nach dem letzten Byte ein ACK senden
> muss?

Auch da hab ich leider schon alles ausprobiert :-\ Momentan sende ich 
ein NACK, dann STOP. Obwohl ein STOP nach einem NACK ja eigentlich eh 
praktisch nicht geht, da SDA ja schon auf high ist und somit kein 
Wechsel von low auf high bei bereits high-stehender SCL-Leitung möglich 
ist.

Jetzt gerade geht's übrigens schon seit ner Stunde...abwarten.

> Auch da hab ich leider schon alles ausprobiert :-\ Momentan sende ich
> ein NACK, dann STOP. Obwohl ein STOP nach einem NACK ja eigentlich eh
> praktisch nicht geht, da SDA ja schon auf high ist und somit kein
> Wechsel von low auf high bei bereits high-stehender SCL-Leitung möglich
> ist.

Schau dir das I2C Protokoll nochmals genau an. Ein Stop geht
sehr wohl und ist sogar eindeutig. Vieleicht liegt es ja gerade daran.

Ralf

Ralf schrieb:
> Schau dir das I2C Protokoll nochmals genau an. Ein Stop geht
> sehr wohl und ist sogar eindeutig.

Ich habe mir das alles bereits mehrfach angeguckt. Was habe ich denn 
dann genau nicht verstanden?

Wenn ein NACK vom Master kommt, dann ist danach SDA high und SCL auch, 
da IDLE high. Ein STOP ist ein Wechsel von low nach high während SCL 
high ist.

Oder was check ich grad nicht?

P.S.: Noch läufts, hab aber auch noch nicht debugged...:-\

Du bist doch der Master, d. h. du steuerst das ACK/NACK
Signal, dann musst du es halt vor der naechsten SCL Flanke
wieder auf low setzen.

OK, aber mein USI-Modul für den I²C belässt den SCL nach dem 8. Bit ja 
auf high. Dann kommt mein NACK/ACK, also geht SCL wieder auf low, setzt 
SDA, dann SCL wieder high um das Bit in den Slave zu takten und dann 
bleibt es wieder im IDLE high. In dem Bild geht SCL erstmal wieder auf 
low und dann wieder auf high, während SDA auf low ist, was einem ACK 
nach einem NACK gleicht. Dann OK, kommt SDA auf high, während SCL schon 
high ist. Das entspricht STOP.

Ich komme eher aus der FPGA Ecke und meine
I2C Master im FPGA funktionieren alle auf
diese Weise (wie im PDF). Damit hatte ich
noch nie Probleme und die laufen stundenlang.
So ist es uebrigens auch in der I2C Bus
Specification von Philips beschrieben.

Ich hab öfter erlebt, daß ein I2C Slave hängt. Das passiert z.B. bei 
einem Read, wenn kein Byte gelesen oder das letze nicht mit NACK geholt 
wird. Ein Stop danach löst das Problem nicht. Als Abhilfe takte ich die 
SCL Leitung mindestens 9 mal. Danach geht alles wieder.

MfG Klaus

Ralf schrieb:
> Ich komme eher aus der FPGA Ecke und meine
> I2C Master im FPGA funktionieren alle auf
> diese Weise (wie im PDF). Damit hatte ich
> noch nie Probleme und die laufen stundenlang.
> So ist es uebrigens auch in der I2C Bus
> Specification von Philips beschrieben.

OK. Aber ist verständlich was ich meine? Es ist ja wirklich ein extra 
CLK-Puls. Also ein Bit mehr. :-\

Ich versteh nicht so recht was du meinst.
Du hast genau 9 steigenende SCL Flanken
die ersten 8 sind das Byte und der 9. ist
das ACK/NACK. Dananch geht das ACK/NACK
auf low solange SCL noch auf low ist.
Jetzt sind SCL und SDA auf low. Dann
kommt die Stop Sequenz (das waere dann
die 10. steigende SCL Flanke).
Schau mal ins angehaengte PDF FIg. 10
auf Seite 13.

So, jetzt habe ich wieder das Problem. Flashe ich das Programm während 
des Betriebes neu drauf, dann kommt wieder das bekannte Muster. Ziehe 
ich den Strom ab und stecke ihn wieder dran, dann gehts. Das Ding hängt 
irgendwie.

Ralf schrieb:
> Du hast genau 9 steigenende SCL Flanken
> die ersten 8 sind das Byte und der 9. ist
> das ACK/NACK.

In dem Bild hast du 10 steigende CLK-Flanken. Ich kann in meinem 
USI-Modul garnicht SCL nochmal händisch auf low bringen. Das ist durch 
das Special-Function gesperrt.

OK, ich probiere jetzt mal erst noch ein low nach dem N/ACK und dann 
STOP. Also ein Bit mehr

Ich verstehe die Welt nicht mehr...

Guckt mal bitte der Code hier:

1

switch( mcp3425_control.sm_state )

2

...

3

4

case SM_GENERATE_START_AND_SEND_ADDRESS:

5

{

6

  USISRL = 0x00; // Output latch to 0x00 (SDA), CLK is high -> START

7

  USICTL0 |= USIGE | USIOE; // Enable output and make latch transparent

8

  USICTL0 &=~USIGE; // Latch back to shift clock controlled

9

10

  if( mcp3425_control.flags )

11

  {

12

    if( mcp3425_control.flags & MCP3425_WRITE_CONFIG_FLAG )

13

    {

14

      USISRL = 0x00; // Write operation -> LSB '0'

15

    }

16

  }

17

  else

18

  {

19

    USISRL = 0x01; // Read operation -> LSB '1'

20

  }

21

22

  USISRL |= MCP3425_DEVICE_CODE | MCP3425_ADDRESS;

23

  USICNT |= 8;

24

25

  mcp3425_control.sm_state = SM_RECEIVE_N_ACK;

26

27

  break;

28

}

29

30

...

So...das funktioniert nicht. Wenn ich es reinflashe, dann kommt als 
Antwort wieder nur 00000001 11111111 11111111...und das dauerhaft.

Wenn ich jetzt aber:

1

  if( 0 )

2

  {

3

    if( mcp3425_control.flags & MCP3425_WRITE_CONFIG_FLAG )

4

    {

5

      USISRL = 0x00; // Write operation -> LSB '0'

6

    }

7

  }

8

  else

9

  {

10

    USISRL = 0x01; // Read operation -> LSB '1'

11

  }

...dann geht es nicht direkt, aber wenn ich den Strom neu dranstecke.

Und glaubt mir, .flags ist 0x00. Wenn ich da nen Breakpoint reinsetze, 
wird die Stelle nie erreicht.

Ich habe jetzt übrigens den 10. Clock-Puls drin. Ist wohl besser und 
scheint auch so zu müssen, hab nochmal ins DB geguckt.


ABER: WAS IST HIER LOS?

Also dieses Phänomen ist absolut reproduzierbar!

Bitte Leute, helft mir :-\

Also bei mir bleibt SCL nach jedem fertigen Byte, oder auch nach einem 
ACK auf high. Egal, ob Interrupt-Flag vor oder nach Operation gelöscht.

Dann brauche ich wohl den letzten zusätzlichen Takt nach dem Stop-Bit 
auf jeden Fall. Also nach dem NACK noch ein zusätzliches low, danach ist 
SCL auf high und das zu der Zeit "lowe" SDA ziehe ich dann auf high.

Sehe ich das richtig?

So, jetzt melde ich mich mal zurück.

Peter Dannegger schrieb:
> Was für ein MC?

Ein MCP430G2402. Ich benutze das integrierte USI-Modul, welches ein 
bisschen Unterstützung für I²C mitbringt, aber nicht den vollen Umfang, 
wie die großen USCI-Module hat.

Hauptaugenmerk meines Interesses liegt momentan an dem Von Peter 
angesprochenen Differenz zwischen Spezifikation und Realität hier beim 
USI-Modul.

Meinen Quelltext werde ich gleich mal anhängen. Vorab habe ich aber 
erstmal das Senden eines Config-Bytes an den ADC mit dem Oszi 
aufgefangen. Die Pegel, bzw. der gesamte Datenstrom für das Senden ist 
jetzt ersichtlich und gleicht auch exakt dem, wie er im DB vom MCP3425 
vorgesehen ist.

Es sind insgesamt 19 steigende Flanken vom CLK-Signal, ein Bit musste 
ich dafür aber zusätzlich einfügen, da es vom USI-Modul her nicht von 
alleine kommt. Wie gesagt, SCL bleibt nach der letzten steigenden Flanke 
high und geht nicht, wie von Peter angemerkt, auf low zurück, solange 
das IFG nicht gelöscht ist.

Bei der Configuration des USI-Moduls habe ich folgende Einstellungen:

- SF-Register für SCL/SDA
- uC ist Master
- I²C-Mode
- Interrupts enabled (Interrupt tritt ein, wenn das Schiebe-Register 
leer getaktet ist)
- Clock Divider 32 (8MHz Systemtakt)
- SMCLK als Quelle
- Clockphase: Datenwechsel bei erster, Übernahme bei zweiter Flanke
- Clock-Idle-Polarität: HIGH

Der Idle-State 'high' ist doch richtig, oder? So ist es zumindest auch 
im DB beschrieben. Die Pull-Ups ziehen die Leitung ja auch hoch.


Nochmal zur Info wie es hier abläuft:

Ich gehe in die State-Machine, setze SDA auf Ausgang und erzeuge die 
START-Bedingung, indem ich SDA auf 'low' ziehe (ohne CLK), während SCL 
noch 'high' ist.

Dann schreibe ich 8Bit in den Puffer (Adresse) und starte das Austakten 
der Bits. In der Zeit wird ins Hauptprogramm zurückgekehrt. Ist der 
Puffer leer, so kommt der Interrupt und die Statemachine wird wieder 
aufgerufen.
SCL ist in diesem Moment 'high', es hat seinen letzten Pegel, also die 
steigende Flanke für das Übernehmen des letzten Bits übernommen.

Es kommt der nächste State, indem das ACK des Slave analysiert werden 
soll. Also setze ich SDA auf Input und takte ein Bit raus.

Interrupt -> In der Statemachine wird das LSB des Empfangspuffers 
geprüft. Es liegt ein ACK (also 'low') vor. Device hat geantwortet. Ich 
schreibe das Config-Byte in den Puffer, setze SDA auf Ausgang und takte 
8 Bits raus. In der Zeit wieder in die main().

Interrupt -> Wieder ACK abfragen, also SDA auf Eingang, 1 Bit raus.

Interrupt -> ACK vorhanden. SCL ist wieder 'high'.

JETZT KOMMT DER INTERESSANTE PUNKT: SCL ist in diesem Moment 'high', SDA 
ist wegen dem ACK 'low'. Theoretisch müsste ich jetzt nurnoch SDA auf 
'high' ziehen und hätte die STOP-Bedingung. Aber im DB ist halt noch ein 
Takt mehr drin, insgesamt 19 steigende Flanken.

Also sende ich noch 1 Bit und dann STOP. So habe ich es gleich wie im 
DB.


Soweit erstmal. Alles OK? Trotzdem dieses "SCL sollte 'low' 
sein"-Problematik. Wieso das eine extra Bit? Mal angenommen, es wäre ein 
NACK gewesen, dann wäre SCL 'high' und SDA 'high'. Hier müsste auf jeden 
Fall erst SDA wieder auf 'low', dann wieder auf 'high' gehen, damit die 
STOP Bedingung erfüllt ist.

Was sagt ihr bis dahin dazu?

Knut Ballhause schrieb:
> MSP430G2402 vielleicht? ;-)

Ja, klar!

Knut Ballhause schrieb:
> Dein Oszillogramm sieht ziemlich abenteuerlich aus.

Ja, die Rs sind wohl noch zu groß, aber es funktioniert. Dennoch liegt 
mein Hauptaugenmerk jetzt gerade auf der Diskussion mit der SCL-Leitung. 
Habe mir die Spec jetzt auch mal durchgelesen, da steht es ja ganz klar 
drin. Aber hier bei mir bleibt SCL IMMER nach der letzten steigenden 
Flanke auf 'high'.

Knut Ballhause schrieb:
> Abgesehen davon ist Dein "zusätzliches Bit" die nötige Stop-Kondition!
> Achte mal ganz genau auf die HIGH und LOW-Pegel der Clocks im
> Datenblatt.

Nee, genau hingesehen nicht. Wenn SCL low bleiben würde nach dem letzten 
Bit, dann wäre der CLK-Puls nicht nötig. Bei einem vorherigen ACK ist es 
auch OK, Dann folgt eine low-high-Flanke. Aber was ist nach einem NACK? 
Dann ist bei mir SCL auf high und SDA auf high. Dann müsste doch SDA 
erst wieder low, dann wieder high.

Knut Ballhause schrieb:
> Zum Einen erreichen
> die Clocks bei schnellen Wechseln nie wirklich den HIGH-Pegel

Das sieht bei Open-Collector Signalen nun mal so aus. High heißt nicht 
der höchste Pegel sondern nur oberhalb der Schaltschwelle. Man hat sich 
nur bei CMOS Logic angewöhnt, daß High gleich Versorgung ist. Da der 
Slave ein ACK bei seiner Adresse erzeugt, hat er alles verstanden, die 
Pegel sind also ok.

MfG Klaus

Also ich habe mir jetzt nochmal einen Brekapoint in die ISR gesetzt.

Diese ist so:

1

USI_ISR()

2

{

3

  rufe state machine auf();

4

  BREAKPOINT

5

  loesche Flag;

6

}

Das Flag wird also gesetzt, die ISR wird aufgerufen, die statemachine 
durchlaufen. Dann der Breakpoint. Flag ist noch gesetzt.

UND: SCL is 'high'. Also definitiv

Knut Ballhause schrieb:
> Aber bestimmst nicht Du, respektive Dein Programm/der Controller den
> Zustand von SCL?

Quasi. Dadurch, dass das USI-Modul den Zugriff auf die Pins hat, steuert 
es diese auch komplett. Eine Manipulation ist auch nicht möglich durch 
eine Pegelzuweisung.

Der geht halt in die Registereinstellung "IDLE-HIGH" zurück. Würde wohl 
nur durch ständiges Umschalten gehen, aber das ist doch nicht Sinn der 
Sache.

Knut Ballhause schrieb:
> Die Daten erscheinen bei einer High/Low-Flanke an SCL und sind aber erst
> gültig bei Low->High.

Das ist mir klar. Hier ging es mir ja auch nur um die Bedingung, dass 
SDA nach SCL auf high geht.

Peter Dannegger schrieb:
> D.h. USISCLREL muß 0 sein, dann bleibt SCL solange low, bis USIIFG
> gelöscht wird.

Hi Peter!

Das Bit ist bei mir nicht gesetzt! Ist es sogar per default nicht. Egal, 
ob gesetzt oder nicht. SCL bleibt high, auch mit gesetztem IFG.

Das Bit schient keine Wirkung zu haben.

Anbei mein Screenshot. Breakpoint gerade in der ISR (Daten wurden 
Übertragen).

IFG ist gesetzt, USISCLREL ist gelöscht.

Auf dem Oszi: SCL ist gelb, SDA blau

Im Errata ist auch nichts drin.

OK, hier steht wie es läuft.

Widerspricht das jetzt also den Spezifikationen?

Das gilt also nur für den SLAVE-Betrieb.

IsquareC-Hans schrieb:
> Knut Ballhause schrieb:
>> Dein Oszillogramm sieht ziemlich abenteuerlich aus.
>
> Ja, die Rs sind wohl noch zu groß, aber es funktioniert.

Das sieht nicht nur abenteuerlich aus, sondern verletzt
deutlich die Timing-Specs des MCP3425:
In den I2C-Specs des Datenblattes steht ganz klar für SDA und SCL,
daß im fast-I2C-mode die maximale rise time bei 300ns liegt!

da liegst Du satt drüber, wenn ich mir das Oszillogramm so ansehe...

Setup- und Hold-Zeiten sind auch noch ein Thema.


Fazit: bei dem Oszillogramm wundert mich gar nix.
(höchstens, daß es überhaupt mal funktioniert)

Gruß,
Thosch

So, es funktioniert jetzt alles!

Ist irgendwer interessiert an der State-Machine für die MSPs mit USI 
(nicht USCI)-Module (kleinere Derivate) zur Kommunikation mit dem 
MCP3425?

Dann würde ich die hier rein stellen.


Auf jeden Fall danke ich euch für eure Hilfe!

Knut Ballhause schrieb:
> Was genau hast Du geändert?

Es lag an nicht immer korrekten STOPs. Irgendwie hat sich die 
Kommunikation dann manchmal verhaspelt.

Auf jeden Fall ist es jetzt alles korrekt und funktioniert einwandfrei.

Thosch schrieb:
> In den I2C-Specs des Datenblattes steht ganz klar für SDA und SCL,
> daß im fast-I2C-mode die maximale rise time bei 300ns liegt!

Da hast du recht. Hab aber auch noch die 10k Widerstände drin. Mit 
weniger sieht es schon ganz anders aus.