TWI hängt sich auf CLK Puls geht unter

Tastköpfe sind auf 1:1.
Habe auch gerade noch ein altes Tektronix 200Mhz Scope an die SCL 
gehängt. Bei dem Scope geht leider nur noch ein Kanal. Auf jeden Fall 
sind auch hier die Flanken sehr schwach. Ich probiere es mal aus die 
Pullups zu verkleinern. Vll bekomme ich auch die Kapazität der Leitung 
gemessen.

Michael schrieb:
> das
> kleinste mit 10MHz, hier ist meiner Meinung nach die zu schwache CLK zu
> sehen.

Deiner Meinung nach hast du einen "schwachen" Clock.

Meiner Meinung nach hast du mit dieser Messung und Darstellung nur
bewiesen dass du ein Mess-System anwendest das für deinen Zweck
nichts taugt.

Dein Mess-System (Oszilloskop oder Tastkopf oder beides) haben
nicht genug Bandbreite um deine Messaufgabe genau genug zu
erfüllen.

Also: nix "schwache CLK", sondern bandbegrenzendes System das
die die Flanken verschleift und nicht nachvollziehbar macht

Das mag sein. Deshalb erwähte ich auch die 10MHz. Habe deshlab gerade 
nocheinmal mit dem Tektronix verglichen. Bin jetzt mit dem Bustakt auf 
50kHz zurückgegangen um Messfehler auszuschließen. Beide Tastköpfe (von 
PicoScope 10MHz und Tektronix) zeigen einen ordentlichen Rechteck am 
Calibrator pin (100kH Signal).

Dennoch glaube ich das es an der "schwachen" Clock liegt. Es wäre schon 
purer Zufall, dass immer wenn die Übertragung funktioniert, das Scope 
die Clk Pulse "sauber" erfasst und nur bei Fehlerhafter Übertragung die 
Bandbreite mal gerade nicht reichte um die Clock wie sonst darzustellen.

Michael schrieb:
> Dennoch glaube ich das es an der "schwachen" Clock liegt.

Welche Fakten bringen dich denn dazu von "schwach" zu sprechen.

Stelle mal dein physikalisches Übretragungssystem (Sender bis
Empfänger) für uns nachvollziehbar dar, dann reden wir über
"schwach"

Bernd K. schrieb:
> Probiers docch mal aus. Schau in die Datenblätter aller Geräte wieviel
> Strom das schwächste davon maximal an seinen I²C-Pins versenken kann und
> rechne Dir entsprechend aus wie klein der Pullup sein darf.

Da braucht man nicht schauen, ein standardkonformer I2C Treiber muß 3mA 
und 400 pF schaffen.

MfG Klaus

Ich glaube aber nicht, daß es wirklich ein HW Problem ist. Wenn man sich 
die Fehlerbilder genau ansieht (ist bei der Auflösung nicht leicht) 
erkennt man CLK-Signale, die extrem niedrig sind. Gleichzeitig sind sie 
aber auch kürzer als die anderen. Da Slaves nur verlangsamen können, 
muß da ein Timing-Problem beim Master sein. Da das nicht immer auftritt, 
könnte ich mir eine Störung durch einen Interrupt oder ein ähnliches 
asynchrones Ereigniss vorstellen.

MfG Klaus

Bernd K. schrieb:
> Nein, das hat mit der Bandbreite des Messwerkzeugs nichts zu tun.

Jetzt wo ich mir es nochmal anschaue muss ich dir Recht geben.
Es sind ja hochfrequente Spikes zu sehen.

Die Pullups sind auf jeden Fall zu schwach, bzw die Clockrate zu hoch.

isidor schrieb:
> Die Pullups sind auf jeden Fall zu schwach, bzw die Clockrate zu hoch.

Grundsätzlich würde ich auch kleinere Pullups nehmen, bei 3.3V so 2k2.
Aber hier sind beliebig viele Takte fast (wären ganz, wenn Pullup 
kleiner) korrekt im Pegel und einzelne dann wieder nicht. Die Pullups 
ändern sich zwischendurch nicht!
Das Timing kann man nicht genau ausmachen, die 'langsame' Anstiegszeit 
ist aber typisch - eben wegen des Pullups.
Bei dem Problempunkt schient mir die Periodendauer einmal zu klein zu 
sein.

Ich tippe auf ein Problem im Master - Software.

Übrigens, die Bandbreite des Skopes ist für diesen Zweck ok, denn sonst 
würden die fallenden Flanken nicht so steil dargestellt.

Michael Reinelt schrieb:
> Das Problem ist eindeutig und ausschließlich der zu kurze Clk-Puls.

.... der aber nicht durch die Prozessor-Hardware verusacht sein muss.

Mir machen die starken Spikes zu denken. Es gibt starke
"undershoots" aber auch Überschwinger, die können das Bussystem
durecheinander bringen. Es kann natürlich eine Fehlmessung
des Oszilloskops sein, oder ein magelhafter Massebezug.

Wichtig ist es die Bus-Topologie geradlinig auszuführen und
keine wilden Stern-Anordnungen zu wählen. Niederohmige Pullups
vermindern auch die Über-/Unterschwinger. Aber auch eine
"innige" Masseverbindung unter allen Busteilnehmern ist wichtig.

Haben wir schon über ausreichend Abblock-Kondensatoren gesprochen?

Michael Reinelt schrieb:
> Übrigens: Die messung gehört unbedingt mit 1:10 Taskopf wiederholt. Dann
> sind die Flanken vermutlich auch wesentlich sauberer.

Das eben nicht. Denn ein 1:1 Tastkopf würde die scharfen Spikes
glattbügeln. Die Spikes sind wesentlich steiler als die
Signalflanken am I2C Bus. Daher hat der Bus selbst ein Problem.

isidor schrieb:
> Die Spikes sind wesentlich steiler als die
> Signalflanken am I2C Bus. Daher hat der Bus selbst ein Problem.

Oder die Spikes werden direkt in den Tastkopf eingestreut und haben gar 
nichts mit der Schaltung zu tun. Solange der Tastkopf mit den unsäglich 
langen Masseclips irgendwo an GND geklemmt wird, solange glaube ich 
nicht, dass die Spikes auf dem Bus vorhanden sind.
Schließe mal deinen 10:1-Tastkopf mit dem Massclip kurz und halte das 
Gebilde über einen Schaltregler ...

HildeK schrieb:
> Oder die Spikes werden direkt in den Tastkopf eingestreut und haben gar
> nichts mit der Schaltung zu tun.

Da hast du allerdings auch wieder Recht. Dann gilt wieder mein
Eingangs erwähntes Bandbreite-Problem ..... dagegen spricht aber
dass das Oszilloskop nur 10 Mhz Bandbreite hat, solche Spikes
sind dafür gefühlsmässig schon zu hochfrequent, könnten also
bei der Bandbreite gar nicht in Erscheinung treten

..... und es gilt: wer misst, misst Mist.

Also eigentlich müssten wir alle selbst dabei sein .....

Danke erstmal für die zahlreichen Tips.
Nachdem ich den I2C nun mit 50 kHz betreibe sehen die Flanken schon 
deutlich besser aus. Zusätzlich habe ich die Pullups noch verringert 
(jeweils 2k35). Noch schönere Flanken. Bis gerade eben funktionierte 
auch alles ganz gut. Nach 5h 12min ist er dann doch wieder hängen 
geblieben. Diesmal aber mit korrekter Übertragung auf dem Scope. Das Ack 
kam noch, dann wurde Stop gesendet und dann war es vorbei. 8022146 
Pakete hat er geschafft. Danach verbleibt die Datenleitung wieder auf 
Low, SCL ist high. Wieviel Zeit dazwischen vergeht kann ich nicht sagen. 
Das habe ich leider nicht mit auf dem Schirm. Ist bloß der Aktelle Pegel 
wenn ich aus dem Single Modus raus gehe.

Muss auch gestehen, dass ich den Debugger zwar angeschlossen hatte aber 
irgendwie nicht gestartet :) Lief quasi stand alone.

Bevor ich irgendwas weiter sage, lasse ich es noch einmal die Nacht über 
laufen. Nicht dass jetzt der deaktivierte Debugger noch irgendwie 
reingespuckt hat, da das AVR Studio auch noch offen war und ich dort 
trocken etwas Code sortiert habe.

Hier auch mal der Code. Wundert euch nicht dass hier noch so viele 
Printfs oder zusätzliche (unnütze) Abfragen drinn sind. Ich war / bin 
ziemlich verzweifelt mit dem twi :/

Im prinziep, startet das Ganze sobald was im Puffer steht 
(SlaveAdresse,SlaveInternAdresse,Datenbyteanzahl,Byte1,Byte2) über die 
Funktion Twi_Tx_TriggerNextTransfer(). Danach ist der Handler dran.

1

void Twi_Tx_TriggerNextTransfer(Twi *p_twi){  

2

  uint8_t buffer_out = 0; 

3

  gl_twi0_state = TWI0TX_BUSY;

4

  /* Set write mode, slave address and 3 internal address byte lengths */

5

  p_twi->TWI_MMR = 0;

6

  if (TWI0->TWI_SR & TWI_SR_TXRDY){

7

    if (Twi0_TxBufferOut(&buffer_out)){  

8

      p_twi->TWI_MMR = TWI_MMR_DADR(buffer_out)| ((1 << TWI_MMR_IADRSZ_Pos) & TWI_MMR_IADRSZ_Msk);

9

      if (Twi0_TxBufferOut(&buffer_out)){

10

        // Set internal address

11

        p_twi->TWI_IADR = 0;

12

        p_twi->TWI_IADR = buffer_out;

13

      }

14

    }

15

    //Enable Interrupt -> interrupt will occur immediately because the TXCOMP and TXRDY Flag is set

16

    TWI0->TWI_IER =  TWI_IER_TXRDY | TWI_IER_TXCOMP | TWI_IER_NACK;

17

  }

18

}

19

20

enum {TX_BEGIN,TX_DATA,TX_END,TX_STOP};

21

22

void TWI0_Handler (void){

23

  static uint32_t status = TX_BEGIN;

24

  static uint32_t cnt;

25

  uint32_t twi_status;

26

  uint8_t buffer_out;

27

28

  if (status == TX_BEGIN){

29

    // Load count of Databytes

30

    if(Twi0_TxBufferOut(&buffer_out)){

31

      cnt = buffer_out;

32

      if (cnt == 0){

33

        //ERROR

34

      }

35

      status = TX_DATA;

36

    }

37

  }

38

39

  if (status == TX_DATA){

40

    twi_status = TWI0->TWI_SR;

41

    if (twi_status & TWI_SR_NACK) {

42

      printf("ED");

43

    }

44

    else if (twi_status & TWI_SR_TXRDY) {

45

      if(Twi0_TxBufferOut(&buffer_out)){

46

        TWI0->TWI_THR = buffer_out;

47

        cnt--;

48

      }

49

      else {

50

        Twi0_TxBufferClear();

51

        status = TX_BEGIN;

52

      }

53

    }

54

55

    if (cnt == 0){

56

      //all bytes send, wait for TXRDY to send STOP

57

      status = TX_END;

58

    }    

59

  }

60

61

  else if (status == TX_END){

62

    twi_status = TWI0->TWI_SR;

63

    if (twi_status & TWI_SR_NACK) {

64

      printf("EE"); //bus läuft nach diesem Fehler weiter -> da nur das letzte Byte nicht verstanden wurde

65

    }

66

    else if (twi_status & TWI_SR_TXRDY) {

67

      TWI0->TWI_CR = TWI_CR_STOP;  

68

      status = TX_STOP;

69

      TWI0->TWI_IDR =   TWI_IDR_TXRDY;

70

    }

71

  }

72

73

  else if (status == TX_STOP){

74

    twi_status = TWI0->TWI_SR;

75

    if (twi_status & TWI_SR_NACK) {

76

      printf("ES");

77

    }

78

    if (twi_status & TWI_SR_TXCOMP) {

79

      status = TX_BEGIN;

80

      printf("t");

81

      //DISABLE INTERRUPT

82

      TWI0->TWI_IDR =   TWI_IDR_TXCOMP | TWI_IDR_TXRDY | TWI_IDR_NACK;

83

      gl_twi0_state = TWI0TX_CMPL;

84

    }

85

    else if (twi_status & TWI_SR_TXRDY) {

86

      status = TX_BEGIN;

87

      printf("X");

88

      //DISABLE INTERRUPT

89

      TWI0->TWI_IDR =   TWI_IDR_TXCOMP | TWI_IDR_TXRDY | TWI_IDR_NACK;

90

    }

91

92

  }

93

}