Probleme mit I2C-Verbindung

Das ist vorkonfektionierte Hardware, au=DFerdem denke ich nicht, dass die =DCbertragung =FCberhaupt so weit kommen w=FCrde

Ok, ich werde mal Vcc mit aufzeichnen

joah, das ist der ACK

Ich lass zur Zeit eh nur das Demoprogramm von Fujitsu laufen. Bei dem verharrt er dann ewig in den entsprechenden Warteschleifen.

Habe jetzt mal die beiden Boards getrennt. Und wollte das Demo-Programm ohne Slave mal abspielen. Dabei stellte sich heraus, dass durch das setzen der Port Function Register auf die I2C Funktion, keine Pull-Ups aktiviert werden. Dies geschieht auch nicht durch das Enable Bit des I2C-Moduls.

Habe dann mal per Hand die Pull-Ups aktiviert und siehe da, die Leitungen h=E4ngen auf 5V und er versucht die Adresse zu senden:

Auf dem Grafik-Board sitzen die Pull-Ups mit 4k7 gegen 3V3

"Matthias Weingart" schrieb:

Man sollte aber schon denken dass Beispielprogramme auf der Hardware zuverlässig laufen sollten. Da würde ich weitermachen, errata sheets checken? Auch zum board, nicht nur zum controller.

Hab mir grad die Doku zu deinem _board_ mal genauer angeguckt. Schönes Teil, hinreichend komplex mit 1001 Jumpern zum konfigurieren... (Und Fujitsu, nicht die drei Edelsteine :)

JP23 bis JP28 sind supply jumper für alles Mögliche, da könntest du das Richtige unter den vielen Vcc bzw Vdd's mal mit aufzeichnen wie Matthias vorschlägt. (Am Jumpern kannst du auch gut schnell einen Messwiderstand einschleifen).

Ah ja, leuchtet ein.

Das board ist ein reinstes Jumpergrab... sind alle Jumper richtig gesetzt für deine Hardware-Konfiguration?

Muss jetzt leider los. Sind irgendwo jumper für die I2C pull-up Widerstände? Wenn ja, sind die richtig gesetzt?

Hallo.

snipped-for-privacy@googlemail.com schrieb:

g 86276-lime.html Ich habe auch mal aehnliche Probleme gehabt, dabei laeuft mein Bus=20 gerade mal mit einigen kHz, allerdings in elektrisch rauher Umgebung. Es =

hilft, auf die Clockleitung zu warten und erst kurze Zeit nach der=20 Flanke der SCL die Datenleitung zu lesen. Evtl. hilft es auch, diese=20 direkt vor dem Lesen nochmals auf logisch 1 zu setzen. Problem bei mir=20 ist, dass die Portpins beim Umschalten gelegentlich etwas langsam sind. Fazit: Ich habe eine Routine, die nichts weiter tut, als einige NOPs zu=20 warten, um den Pins genuegend Zeit zu geben. Auch wenn der Slave SCL=20 wieder freigibt, heisst das noch lange nicht, dass er wirklich=20 empfangsbereit ist. Er schaltet lediglich seine Portpins gerade um.

Noch ein Tipp: Wenn die Strecke zwischen den Boards laenger ist oder=20 elektromagnetischen Feldern ausgesetzt wird (die Rippel auf der Leitung=20 koennten auch NDR1 sein ;-) ) hilft vielleicht ein Optokoppler auf jedem =

Board, dazwischen eine Stromschleife. Am Collector natuerlich die=20 entsprechenden PullUps.

Gruss, Clemens

Hallo,

das Verfahren ist in Hardware implementiert (I2C-Controller). Ansonsten sind die Boards direkt miteinander gekoppelt, ohne Kabel

Gru=DF Christian

Christian Eyrich :

Wär 'ne Option. Schreib die I2C-Routine in Software. Viel weniger Ärger! :-)

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

"Matthias Weingart" schrieb:

:))

Stimmt aber, in SW isses easy peasy. Nie Probleme gehabt.

Zu deinem Codeschnipsel:

Das Flussdiagramm im ds. p.689 erzählt was anderes, andere Reihen- folge des Einschaltens (erst BER, dann EN, dann Adresse...). Ausserdem scheinst du INT überhaupt nicht zu bedienen?

Warum ICCR0_EN = 0 zu Beginn?

Du schriebst, du hast das 1:1 von einer Beispielapplikation übernommen. Von welcher? (link bitte)

Hab mir auch mal eine Beispielroutine vom Hersteller angesehen, AN 90330_i2c_0-v12.zip.

Was dort steht, passt wiederum wunderbar zum Flussdiagramm im ds.

void I2C_Start(unsigned char slave_address) { do { IBCR0_BER = 0; // clear bus error IF ICCR0_EN = 1; // enable I2C interface IDAR0 = slave_address; // slave_address is sent

IBCR0_MSS = 1; // master mode and start cond. IBCR0_INT = 0; // clear transfer end IF while(IBCR0_INT == 0); // look if transfer is in process } while (IBCR0_BER == 1); // retry if Bus-Error detected

while(IBSR0_LRB == 1) // no ACK: device not ready { // maybe last write not fin. yet IBCR0_SCC = 1; // try restart (= continue) while (IBCR0_INT == 0); // wait that transfer is finished } }

Wenn man sich das so anschaut ist es stimmig und passt auch zum Flussdiagramm im ds.

Deine Init-Routine und die aus der zit. AN weichen auch voneinander ab, du schaltest das Modul am Ende ein, Fujitsu macht es schon vor der Schalterei in IBCR0, du aber erst danach. Bist du sicher dass du Zugriff auf IBCR0 hast wenn das Modul ausgeschaltet ist?

(p.671: "The BER bit must be cleared before the interface may be reenabled." fällt auch ins Auge weil kursiv gedruckt)

Also nochmal die Frage der Fragen: Aus welcher Beispielapplikation hast du deine Routinen her?

Christian Eyrich :

Also doch so ein schräges System: Master hat 5V, Slave hat 3.3V. Dann dürfen wirklich nur im Slave pullups-gesetzt sein. Der Master muss OpenDrain sein! Bitte auch die Pullups in der CPU deaktivieren. Sonst gibt es Queströme von Deinem 5V Ausgang durch die Schutzdioden des Slaves auf die 3V3 (könnte problematisch sein, glaube aber nicht, dass das die Ursache ist). Falls der Master dann noch das Schaltpotential der Eingänge auf Vcc/2 hat (also 2,5V), dann wird es echt knapp und man braucht sich nicht zu wundern, dass es bei hoher Speed nicht läuft (normalerweise liegt die Schaltschwelle aber meist bei 1-1.5V). Solltest auf jeden Fall mal beide Vcc's messen 5V und 3V3 (osci).

Gute Idee. Macht der Master dann auch nur 5 Takte?

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

"Matthias Weingart" schrieb:

Hab gesehen dass man das *alles* passend konfigurieren kann auf dem uC-Evalboard.

Die Jumper JP23 bis JP28 kommen dafür wohl in Frage, je nachdem wie die gesetzt sind arbeiten die Ausgänge mit 3.3V bzw. 5V.

Ja, gute Idee. *Originalroutinen* vom Hersteller aus AN nehmen, nicht deine die abweichen!

Dann die Hardware passend konfigurieren, dafür hast du ziemlich genau 100 jumper auf deinem board.

Erst wenn alles geht, die Signale auf dem Bus ordentlich aussehen, dann eigenen Code schreiben/testen.

Momentan hast du kein I2C sondern nen Sägezahngenerator. Die Signale sollten zumindest Ähnlichkeit mit dem haben, was man im ds. auf p.686 sehen kann.

Du kannst auch die Zeitbezüge zwischen SDA und SCL frei über den Prescaler konfigurieren (und damit auch falsch einstellen). Zeitauflösung 2us/skt oder so sollte dann zeigen ob zumindest das stimmt, aus dem bisherigen Bildchen kann man das schlecht ablesen.

Der Reihe nach, nicht gleichzeitig: Erst die Hose, dann die Schuhe!

Ich glaub du hast da was falsch verstanden. Die anderen Routinen sind von mir, hab damit ein bisschen rumgespielt, nachdem das Beispielprogramm von Fujitsu nicht lief. Aber das tut ja nix zur Sache, wie gesagt, die Routinen von Fujitsu laufen auch nicht einwandfrei.

Soweit kommt er ja nicht, weil kein Slave dran h=E4ngt, der auf die Adresse ein ACK gibt. Es bleibt dann beim Repeated Start, der ja in den Originalroutinen implementiert ist

"Christian Eyrich" schrieb:

*nachdenk* *nochmal nachdenk* *zum dritten Mal d'rüber nachdenk*

Deutlicher Hinweis auf Hardwareproblem?

*nachdenk*

deutlichster Hinweis auf Hardwareproblem?

*nochmal nachdenk*

allerdeutlichster Hinweis, falls einer von uns beiden nicht Quark zwischen den Ohren...? (Vorzugsweise der Programmierer, was immer er gemacht haben könnte... :)

Mit anderen Worten: Geht es inzwischen zuverlässig und reproduzierbar u.s.w. ?

Hallo,

der Fujitsu Support k=FCmmert sich derzeit darum, dauert leider aufgrund der Urlaubszeit etwas l=E4nger. Es wird vermutet, dass der Fehler irgendwo in der FPGA-Konfiguration liegt, =FCber den fast alle Signale geroutet werden, wenn ich das richtig verstanden habe