Hallo zusammen,
Versuche seid geraumer Zeit mit meinem STM32F030C8T6 eine stabile I2C
Kommunikation hinzubekommen. Mittlerweile sehe ich aber den Wald vor
lauter Bäumen nicht mehr. Programmiert wurde das ganze in der CoocCox
IDE. Der Controller sitzt auf einer selbst entwickelten Platine und
zeigt so auch keine Auffälligkeiten. An die ganzen Blockkondensatoren
sowohl für den Kontroller als auch für das EEPROM wurden gedacht. Die
I2C Busleitungen werden über 4k7 auf Vcc (3,3 Volt) gezogen. Der
Kontroller läuft mit 44,236 MHz. Die I2C Timings wurden mittels der ST
Excel Tabelle ermittelt.
Steppe ich durch mein Programm im Debugger Schritt für Schritt durch
klappt alles und die Daten werden sauber in das EEPRom geschrieben.
Versuche ich die Schreibfunktion im ganzen auszuführen schreibt er ein
Byte, beim Versuch ein weiteres Byte zu schreiben bleibt er hängen und
bekommt das I2C_FLAG_TXIS nicht gesetzt.
Aufruf der Schreibfunktion:
//Clear the stop flag for the next potential transfer
35
I2C_ClearFlag(I2Cx, I2C_FLAG_STOPF);
36
}
Damit bei Bedarf besser geholfen werden kann, habe ich auch noch das
Komplette Coocox Projekt angehängt.
Wäre super, wenn jemand etwas Licht ins dunkle bringen könnte.
Gruß,
Markus
Moin,
habe kein Coocox, würde aber erst einmal die Takte prüfen.
Hast Du Messmöglichkeiten?
Wenn ja, die Möglichkeiten des MCO nutzen...
Ist die ms korrekt?
Weiterhin ist mir aufgefallen das deine eeprom.c viele \00 enthält.
Weiß aber nicht ob das eine Rolle spielt.
Hallo hp-freund, deine Vermutung geht schon einmal in die richtige
Richtung. Habe gerade mal den I2C Bus oszillographiert. Ich konnte dabei
kaum meinen Augen trauen. Das erste Oszillogram zeigt mehr als deutlich
das die I2C Clock gegen 180kHz geht, was natürlich viel zu schnell für
das EEPROM ist (scope_0.bmp).
Also habe ich darauf nochmal angefangen, alles von Anfang an zu
kontrollieren. Verwendet wird ein 14,745 MHz Quartz. Mit den Coocox
standard Projekten wird versucht den Takt über HSE und einen PLL
Multiplikator von 6 zu erzeugen. Über diese gesamte Konfiguration kann
man auch wunderbar drüber steppen. Nur 14,745 MHz mal 6 sind alles
andere als 44,236 MHz. Ein wunder das der Controller das überhaupt
mitgemacht hat und nicht viel früher ausgestiegen ist.
Nachdem ich dies korrigiert habe, sieht das zweite Oszillogram auch
schon viel besser aus (scope_1.bmp). Und die Frequenz liegt zumindest in
der richtigen Region, wenn sie auch nicht zu 100% getroffen wurde.
Leider ändert das noch nichts an dem beschreiben des EEPRoms. Ein
wiederholtes lesen ist unbegrenzt möglich. Versuche ich Daten in das
EEPROM zu schreiben bleibe ich beim selben Problem hängen das die I2C
Flags nicht sauber ankommen.
Ich werde versuchen spätestens morgen nochmal den MCO Pin zu
oszillographieren damit man ein vollständiges Bild bekommt.
Sollte noch jemand weitere Anmerkungen haben, sind diese herzlich
willkommen.
Ich habe gerade testweise nach jedem Aufruf der EEPRom Schreibfunktion
ein Delay von einer Millisekunde eingefügt. Mit diesem Delay läuft auch
das Beschreiben des EEPRoms ohne Probleme.
Da kann doch, meines Verständnisses nach, nur noch etwas an meiner
Routine faul sein. Es kann ja nicht die Lösung sein ein Delay
einzufügen...
Markus S. schrieb:> Da kann doch, meines Verständnisses nach, nur noch etwas an meiner> Routine faul sein. Es kann ja nicht die Lösung sein ein Delay> einzufügen...
Die Lösung dürfte darin bestehen, daß man das Schreiben des vorherigen
Bytes ins EEPROM auch abwartet. Das ist doch selbstverständlich!
Alternativ gibt es den page mode, bei dem auch mehrere Bytes - Anzahl
steht im Datenblatt - am Stück geschrieben werden können und nur am Ende
gewartet werden muß.