EEPROM 24AA16 arbeitet bei 100kHz aber nicht bei 400kHz

[Eygee (Gast)]

Hallo Zusammen,

in meiner Schaltung sitzt das EEPROM 24AA16 von Microchip, welches 
direkt über die SCL und SDA Ports mit dem µC STM32F205VGT6 verbunden 
ist.
(Kurze Skizze des Schaltungsausschnitts anbei)

Betreibe ich das EEPROM über den I2C Bus mit 100 kHz funktioniert die 
Kommunikation einwandfrei. Ändere ich allerdings die Taktfrequenz auf 
400 kHz ist das EEPROM nicht mehr ansprechbar. Laut Datenblatt ist das 
EEPROM allerdings auch auf 400 kHz ausgelegt sofern man eine 
Versorgungsspannung von > 2.5 V beachtet.


Ich habe bereits versucht die Verbindung niederohmiger zu gestalten 
durch runtersetzen der Pull-Up Widerstände, leider ohne Erfolg.


Hatte jemand schon einmal das Problem, dass ein EEPROM bei 100 kHz 
funktioniert aber bei 400 kHz nicht?

Vielen Dank im Voraus

[Helmut -. (dc3yc)]

Wozu die Kondensatoren? Dadurch machst du doch die Signalflanken 
schlapper! Mach die doch mal raus und schaue ob's dann geht. Außerdem 
würde ich nah am EEPROM einen Abblockkondi reinbauen.

[Peter D. (peda)]

20k ist sehr hochohmig, nimm mal 1,8k.

Der Master sollte Clock Stretching können, d.h. warten, bis SCL wirklich 
wieder auf high ist.

[Jörg R. (solar77)]

Eygee schrieb:
> in meiner Schaltung sitzt das EEPROM 24AA16 von Microchip, welches
> direkt über die SCL und SDA

Woher hast Du die Information Cs an SCL und SDA anzuschließen?

[Andreas B. (bitverdreher)]

Eygee schrieb:
> Hatte jemand schon einmal das Problem, dass ein EEPROM bei 100 kHz
> funktioniert aber bei 400 kHz nicht?
Nö, bin aber noch nie auf die Idee gekommen, da Kondensatoren parallel 
zu schalten. Wie kommt man denn auf sowas??

[Einer K. (Gast)]

Ein Oszi zeigt dir den Fehler in aller Klarheit.

[bingo (Gast)]

Je höher der Takt und je länger die Leitungen, umso niedriger müssen die 
Pullups sein, 1.8 wie von peda vorgeschlagen ist für 400kHz ok. Und die 
Cs müssen unbedingt weg, die verschlechtern die Situation bei jeder 
Frequenz.

[drm (Gast)]

I2C will 4,7k Pullups haben

[Helmut -. (dc3yc)]

drm schrieb:
> I2C will 4,7k Pullups haben

Bei 5V, wir sind hier aber bei 3.3V!

[Einer K. (Gast)]

drm schrieb:
> I2C will 4,7k Pullups haben
I2C will die Spezifikation eingehalten haben.
Mehr nicht....
4,7k sind da nicht immer hilfreich.

[Eygee (Gast)]

Vielen Dank für die zahlreichen schnellen Antworten.

Ich habe die Schaltung bereits mit den Kondensatoren so erhalten und mir 
verkehrterweise keine Gedanken dazu gemacht, da es ja bei 100 kHz 
funktioniert hat.

Kondensatoren sind nun raus und die Pull-Ups auf 1k8 runter, leider noch 
ohne Erfolg.

Werde nun mit dem Oszi weiter machen, melde mich

[jo mei (Gast)]

Eygee schrieb:
> Kondensatoren sind nun raus und die Pull-Ups auf 1k8 runter, leider noch
> ohne Erfolg.

Ich rate mal: du hast am EEPROM keinen Abblock-Kondensator.

Das wäre sträflicher Leichtsinn. Übliche Strafe: Auspeitschen.

[jo mei (Gast)]

.... ähhh .... wozu Abblock-Kondensator? Was ist das?

Geht doch auch ohne! ? ! ? ! ?

[Name: (Gast)]

Schließe mich den anderen an.

20k ist viel zuviel. Nimm 2k oder 1k8. Oder kuck dir wenigstens mal die 
Signale mit dem Oszi an.
Ich wette bei 400kHz schaffen die Haifische mit 20k nur noch 1V oder so, 
das versteht das EEPROM dann nicht mehr.

Wieviele Fragen hier im Forum wären überflüssig, wenn die Leute mal ihre 
Messmittel aus der Schublade nehmen würden...

[Andi B. (andi_b2)]

High und Low Time nach I²C Spec nachmessen sobald du das Oszi drauf 
hast. Übrigens, wenn die Leitungen nicht zu lang sind, werden hier wohl 
auch ca. 5k Pups reichen, muss aber natürlich nachgemessen werden. Oder 
halt aus den Empfehlungskurven vom I²C Standard raussuchen. Ach ja, 
viele Master-uCs können keine wirklichen 400kHz I²C. Irgendwie geht sich 
das anscheinend mit den internen Teiler nicht gut aus. AFAIR wird sonst 
die High Time verletzt. Darum darf man bei vielen Chips (i.MX7, Infineon 
Mips, ....) nur ca. 375kHz I²C Takt einstellen. Manchmal steht das so 
auch in der Spec, aber oft gut versteckt.

[Eygee (Gast)]

Die Signalflanken scheinen nun nicht mehr das Problem zu sein. Ich 
vermute, dass der Fehler Softwareseitig zu finden ist. Nach ersten 
Erkenntnissen scheint ein Flag bei 400 kHz nicht richtig gesetzt zu 
werden.

Vielen Dank für die Hilfestellung, werde mich bei Zeiten dann mal auf 
die Suche im Code machen.