mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32F103: EEPROM Abstürze abfangen


Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

leider kommt es doch immer wieder mal vor, dass meine E2's sich 
aufhängen und das Programm dann endlos in einer Abfrage eines Events 
hängen bleibt. Ich benutze die I2C Hardware des Chips, frage Fehler 
"meistens" ab aber nicht hinter jedem einzelnen Befehl, weil das 
Programm dadurch sehr unübersichtlich wird und es auch keine sinnvolle 
Reaktion darauf gibt, dann steht die Kiste eben still, merke ich an den 
Anzeigen ja. Da das bis zu 4-fach geschachtelt ist muss ein ERROR auch 
bis nach ganz oben an den Aufrufer durchgereicht werden, globale ERROR 
Variable nutze ich nicht.

Man muss halt jede Lib Funktion nochmal kapseln und davon gibt es 
reichlich. Prinzipiell kann jedes Event eben nicht kommen.
static uint8_t i2c_stop()
{
    unsigned int timeout = I2C_TIMEOUT;

    I2C_GenerateSTOP(I2C_KANAL, ENABLE);
    /* Warte bis Stop akzeptiert wurde */
    while (I2C_GetFlagStatus(I2C_KANAL, I2C_FLAG_STOPF))
    {
       if (!(--timeout))
        return ERROR;
    };

    return SUCCESS;
}


Ist allerdings nicht so wie bei einer Soft I2C, dass man mal eben an den 
Pins wackeln kann, die sind schon fest mit der Hardware verbunden und 
manuell gar nicht ansprechbar, das macht die Statemachine des Chips.

Hat da schon mal jemand was Kluges ausgefrickelt, ob solche Aufhänger zu 
resetten? Schalte ich i2C ab gegen die Pins in High-Z, hängen also auf 
+5V. Nützt auch nichts.

Gruss,
Christian

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die I2C Peripherie hat eine Reset Funktion über ein bestimmtes Bit im 
Register. weiß ich grad nicht auswendig, musst du mal nach suchen. Im 
Zweifelsfall einfach über den RCC resetten. Ich verwende für meine 
asynchrone (per Interrupts statt Warte Schleife) I2C Ansteuerung 
nebenher einen Timer, um Timeouts zu erkennen und eben diese Reset 
Funktion zu nutzen. Die I2C Peripherie der STM32 ist da besonders 
zickig, wenn die einen "low" Störimpuls sehen gehen die dauerhaft auf 
"busy" o.ä.

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist mir nicht entgangen:
  // Peripherie Takt einschalten I2C3: PB6 (I2C1 SCL) und PB7 (I2C1_SDA)
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB | RCC_APB2Periph_AFIO, ENABLE);

    I2C_DeInit(I2C_KANAL);
    I2C_Cmd(I2C_KANAL, DISABLE);            // I2C abschalten, damit Bus still bleibt

Mann muss ihn vor der Config abschalten, sonst hat man seltsame 
Glitches, beim LA zu sehen. Aber die Reset Funktion muss ich auch mal 
suchen, bisher noch nicht gewusst, dass es sowas überhaupt gibt.... die 
Idee mit dem Timer ist gut! Da braucht man ja nur eine zeit wo man eie 
Variable zurück setzt und fertig.

Hmmm..... meinst Du 22.6.1: SWRST: Sofwtare Reset Bit?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Mann muss ihn vor der Config abschalten, sonst hat man seltsame
> Glitches
Hm, das Problem habe ich nicht. Ich schalte ihn einfach ein:
RCC->APB2ENR |= RCC_APB2ENR_IOPBEN;
RCC->APB1ENR |= RCC_APB1ENR_TIM2EN | RCC_APB1ENR_I2C1EN;
/* Hier Timing-Konfiguration... */
I2C1->CR1 = I2C_CR1_PE;

Christian J. schrieb:
> Hmmm..... meinst Du 22.6.1: SWRST: Sofwtare Reset Bit?
Ja genau.

Christian J. schrieb:
> Da braucht man ja nur eine zeit wo man eie
> Variable zurück setzt und fertig.
Ich starte/resette den Timer immer wenn eine Operation gestartet wird, 
und wenn der Timer-Interrupt vor dem I2C-Interrupt kommt war das ein 
Timeout, und ich fange ganz von vorne an (reinitialisiere auch den 
externen IC).

Die lieben E-Techniker bauen immer Platinen mit ganz viel I2C weil das 
ja so schön einfach ist, und als Programmierer darf man sich dann mit 
sowas rumschlagen ;-)

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
>> Hmmm..... meinst Du 22.6.1: SWRST: Sofwtare Reset Bit?
> Ja genau.

Und wie "bedient" man das?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Und wie "bedient" man das?
Einfach einschalten?
I2C1->CR1 = I2C_CR1_SWRST;
// Zur Sicherheit Schreibvorgang abwarten
__DSB (); __NOP ();
I2C1->CR1 = 0;
// I2C neu intialisieren

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder so? Bin nicht so der register Fan...

  /* Enable I2C2 reset state */
    RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, ENABLE);
    /* Release I2C2 from reset state */
    RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, DISABLE);

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Christian J. schrieb:
> Oder so? Bin nicht so der register Fan...
>
>   /* Enable I2C2 reset state */
>     RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, ENABLE);
>     /* Release I2C2 from reset state */
>     RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, DISABLE);
Würde ich nur so machen wenn das SWRST Bit nicht geht.

Mit direkten Registerzugriffen zu programmieren find ich einfacher, weil 
die schön ausführlich im Reference Manual dokumentiert sind, und man 
einfach nur machen muss was da steht. Bei den Library-Funktionen muss 
man erstmal in den Source-Code schauen was die überhaupt machen, das mit 
dem Reference Manual abgleichen und sich dann rückwärts überlegen wann 
man welche Funktion aufrufen muss damit die richtigen Bits gesetzt 
werden.

Autor: Arduinoquäler (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Christian J. schrieb:
> Hat da schon mal jemand was Kluges ausgefrickelt, ob solche Aufhänger zu
> resetten?

Du solltest deine Hardware zurechtfrickeln damit dein I2C-Bus
störungsfrei funktioniert.

Herzeigen willst du deinen Aufbau und deine Schaltung ja sowieso
nicht denn dann kämen womöglich grössere Peinlichkeiten ans
Tageslicht.

Also belasssen wir es lieber bei dieser vernebelten Situation
und stochern so weiter. Wenn deine Annahmen über Elektronik
und Schaltungsphysik am I2C Bus so professionell sind wie beim
Thema NRF24 dann ist das auch besser so
(Beitrag "Re: Welche NRF24L01+ 2.4 Ghz Transmitter taugen?").

Und du frickelst besser weiter nur an der Software herum.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduinoquäler schrieb:
> Du solltest deine Hardware zurechtfrickeln damit dein I2C-Bus
> störungsfrei funktioniert.
Das ist nicht zielführend. Oft ist es einfacher/billiger/leichter, 
Fehler in Software abzufangen als alles massiv gegen Störungen zu 
schirmen. Der I2C-Bus ist notorisch empfindlich (insbesondere bei den 
STM32) und eine Fehlerbehandlung ist ohnehin nötig, denn irgendwann wird 
doch ein Fehler auftreten. Leider hat I2C ja weder Checksum noch 
differentielle Übertragung, was da ganze besonders spaßig macht.

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss ich nach dem Reset das Ganze wieder neu initialisieren?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Muss ich nach dem Reset das Ganze wieder neu initialisieren?

Glaub schon... Ruf die Initialisierungsfunktion einfach erneut auf ;-) 
Statt eines externen EEPROMs kann man auch den internen Flash 
beschreiben, wenn man's schlau macht hält der auch genau so lange.

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Christian J. schrieb:
>> Muss ich nach dem Reset das Ganze wieder neu initialisieren?
>
> Glaub schon... Ruf die Initialisierungsfunktion einfach erneut auf ;-)
> Statt eines externen EEPROMs kann man auch den internen Flash
> beschreiben, wenn man's schlau macht hält der auch genau so lange.

Ja.... nur ist der eh schon fast randvoll..... und so einfach ist das 
auch nicht, geht ja nur blockweise.

So.... gucken ob es passt.
void EE_Reset_Hardware() {

      I2C1->CR1 = I2C_CR1_SWRST;
      __DSB ();
      __NOP ();
      I2C1->CR1 = 0;

      /* Enable I2C2 reset state */
      RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, ENABLE);
      /* Release I2C2 from reset state */
      RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C2, DISABLE);

      EE_Init();

}

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

alle 2-3 Tage steht meine schöne Anzeigetafel an der Wald still, weil 
sich der I2C Bus aufhängt. Wo genau weiss ich nicht, hängt ja nicht am 
Debugger aber meist kommt ein sog. Event einfach nicht. 2x EE je 64kb, 
4,7kOhm an 5V, angesteuert durch OD Ausgang des F103.

Blind geschrieben mein Versuch alles was mit I2C zu tun hat, also der 
Master im F103 und das EEPROM zu resetten. Irgendwann schlägt der WDT ja 
zu nach 10s und dann wird immer und immer wieder versucht das EEPRPOM 
anzusprechen.

Hat sich schon mal jemand damit intensiver befasst EE's und anderes aus 
dem Schlaf zu klingeln?
uint8_t EE_Reset_Hardware()
{

  GPIO_InitTypeDef GPIO_InitStruct;       // Port Init Struct

  /* I2C abschalten */
  
  I2C_DeInit(I2C_KANAL);
    I2C_Cmd(I2C_KANAL, DISABLE);      
  
  /* Statemachine resetten */
  
    I2C1->CR1 |= I2C_CR1_SWRST;  // reset the peripheral
     __DSB ();
     __NOP ();
  I2C1->CR1 &= ~I2C_CR1_SWRST; // re-enable
      
  
    /* Enable I2C2 reset state */
    RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C1, ENABLE);
    /* Release I2C2 from reset state */
    RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C1, DISABLE);
  
        EE_Init();
  if (EE_TestDevice(0))
    return SUCCESS;
  
  /* Port mit SCL/SCA als normaler GPIO */
  I2C_DeInit(I2C_KANAL);
    I2C_Cmd(I2C_KANAL, DISABLE); 
  
  /* SCL = Output */  
    GPIO_InitStruct.GPIO_Pin   = I2C_SCL_PIN;        
    GPIO_InitStruct.GPIO_Mode  = GPIO_Mode_Out_PP;         
    GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;   
    GPIO_Init(I2C_SCL_PORT, &GPIO_InitStruct);
  
  /* SDA = Input */
  GPIO_InitStruct.GPIO_Pin   = I2C_SDA_PIN;      
    GPIO_InitStruct.GPIO_Mode  = GPIO_Mode_IN;        
    GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;  
    GPIO_Init(I2C_SCL_PORT, &GPIO_InitStruct);
    
  /* An SCL Pin wackeln und prüfen, ob SDA high get */
  
  _Bool pinstat;
  volatile uint32_t i;
  uint16_t k = 9;
  do {
    GPIO_ResetBits(HC595_CTRL,I2C_SCL_PIN);  
    for (i = 0; i < 60000; i++);
    GPIO_SetBits(I2C_SCL_PORT,I2C_SCL_PIN);
    for (i = 0; i < 60000; i++);
    pinstat = GPIO_ReadBit(I2C_SCL_PORT,I2C_SDA_PIN);
  } while (k-- && !pinstat)
  
  if (pinstat) {
    EE_Init();
    return SUCCESS;
  }
  
  /* Fehler kann nicht behoben werden */
  return ERROR;
}

: Bearbeitet durch User
Autor: Frickelfritze (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Chris J. schrieb:
> Wo genau weiss ich nicht

Ich weiss es auch nicht, aber ich bin mir ziemlich sicher
dass dein (mieser) Hardware-Aufbau schuld ist.

Aber daran kann es ja nach deiner Auffassung sicherlich
nicht liegen. Es ist immer der Hersteller eines Chips oder
der fehlerhafte Compiler dran schuld.

Autor: Hmm (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Arduinoquäler schrieb:
> Christian J. schrieb:
>> Hat da schon mal jemand was Kluges ausgefrickelt, ob solche Aufhänger zu
>> resetten?
>
> Du solltest deine Hardware zurechtfrickeln damit dein I2C-Bus
> störungsfrei funktioniert.

Dem schließe ich mich an.

Man sollte sich mal klarmachen, dass I2C KEINE Maßnahmen zur 
Fehlererkennung- und Korrektur hat. Das verlässt sich auf 0% Fehlerrate 
auf physikalischer Ebene.
Wenn also der Bus aus elektrischen Gründen Bitfehler hat, dann ist das 
Kind schon im Brunnen. Da ist der Fehler auf Hardwareebene zu finden und 
zu beheben.

Was ich aus der Praxis sagen kann:
Ich kann von den I2C-Blöcken von ST nichts negatives berichten. Mein 
Arbeitgeber hat mehrere hunderttausend Platinen mit STM32 und I2C im 
Feld, wo das ohne Probleme läuft.
Was klar sein muss ist, dass I2C ein störanfälliger Bus ist, und 
besondere Sorgfalt verlangt. Er ist aber zuverlässig, vorausgesetzt man 
hat das sauber ausgelegt und in Betrieb genommen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Hat da schon mal jemand was Kluges ausgefrickelt, ob solche Aufhänger zu
> resetten?

Vielleicht solltest Du erstmal versuchen, die Ursache zu finden als an 
den Symptomen herumzudoktern.

Viele I2C-Beispiele, die man so im Netz findet, vergessen nämlich, nach 
einem Daten-Transfer (bzw. vor dem nächsten) I2C_FLAG_BUSY abzufragen. 
Das funktioniert dann solange gut, wie man nur Daten tröpfchenweise 
liest oder schreibt. Kommen zum Beispiel mehrere I2C-Transferblöcke 
direkt hintereinander, hängt sich ohne Berücksichtigung des Busy-Flags 
die I2C-Peripherie einfach weg und ist nicht mehr ansprechbar. Da nutzt 
auch kein 9-maliges Pinwackeln mehr, nur noch ein HW-Reset des STM32.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank M. schrieb:
> Vielleicht solltest Du erstmal versuchen, die Ursache zu finden als an
> den Symptomen herumzudoktern.

Nein! Für das I2C EEPROM baue ich mir eine Schaltung mit MOSFET
damit ich mir bei "Bedarf" das EEPROM aus- und neu einschalten
kann. Das ist wahre Ingenieuerskunst.

Von wegen schlechte Hardware, paahhh ....

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Kommen zum Beispiel mehrere I2C-Transferblöcke
> direkt hintereinander, hängt sich ohne Berücksichtigung des Busy-Flags
> die I2C-Peripherie einfach weg und ist nicht mehr ansprechbar
Es reicht schon eine eingekoppelte negative Flanke...

Frank M. schrieb:
> Da nutzt
> auch kein 9-maliges Pinwackeln mehr, nur noch ein HW-Reset des STM32.
Schon mal das Reset-Bit der I2C-Peripherie ausprobiert? Das hat bei mir 
immer geholfen.

Hmm schrieb:
> Ich kann von den I2C-Blöcken von ST nichts negatives berichten. Mein
> Arbeitgeber hat mehrere hunderttausend Platinen mit STM32 und I2C im
> Feld, wo das ohne Probleme läuft.
Welcher STM32 und synchrone oder asynchrone Ansteuerung? Bei den alten 
(F1, F4) ist die asynchrone Ansteuerung sehr kompliziert, da kann man 
leicht Fehler machen die zu Instabilitäten führen. Diese Komplexität ist 
mMn etwas sehr negatives an dieser Hardware.

Vermutlich hängt sich hier der EEPROM-IC auf. Die Peripherie vom STM32 
wird ja resettet. Hat der IC denn keinen Reset-Eingang?

Frickelfritze schrieb:
> Nein! Für das I2C EEPROM baue ich mir eine Schaltung mit MOSFET
> damit ich mir bei "Bedarf" das EEPROM aus- und neu einschalten
> kann. Das ist wahre Ingenieuerskunst.
Wenns nicht anders geht... Auch bei guter Hardware muss man immer davon 
ausgehen, dass Fehlübertragungen passieren. Die Software müsste dann 
dafür sorgen, dass diese abgefangen werden. Das ist bei I²C, wie wir 
sehen, aber schwierig (keine Checksum, Slave und Master hängen sich 
auf). Bei CAN z.B. wird da explizit drauf geachtet, und temporäre 
Störungen/Verschlucker können einen CAN kaum dauerhaft aus dem Takt 
bringen.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Wenns nicht anders geht... Auch bei guter Hardware muss man immer davon
> ausgehen, dass Fehlübertragungen passieren.

Seltsam. 99% aller PCs haben keine Möglichkeit die Datenübertragung
zwischen Prozessor und Arbeitsspeicher zu validieren da ihnen
die Paritätsprüfung fehlt. Es gibt viele, viele weitere Beispiele
wo man sich auf die Übertragung einfach verlässt. Weil sie in der Tat
zuverlässig ist. Aber hier beim I2C redest du diese Notwendigkeit
herbei. Ich behaupte dass I2C - wenn es richtig gemacht ist - genau
so zuverlässig ist wie ein Speicherinterface (als Beispiel) beim PC.

Aber eigentlich klingt mir diese Meinung eher wie das Fähnchen im
Wind.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Es reicht schon eine eingekoppelte negative Flanke...

Ist bei mir noch nicht aufgetreten.

> Schon mal das Reset-Bit der I2C-Peripherie ausprobiert? Das hat bei mir
> immer geholfen.

Nein, habe ich nicht, aber das werde ich mal testen. Ich bin damals mal 
lediglich in die Busy-Flag-Falle getippt, als ich die ersten Versuche 
mit STM32 und I2C machte. Da orientiert man sich erstmal an bereits 
vorhandenen Sourcen im Netz. Es hat mich nach einigen Recherchen doch 
arg gewundert, wieviele Beispiele im Netz dieses Flag einfach 
schlichtweg ignorieren.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Ich behaupte dass I2C - wenn es richtig gemacht ist - genau
> so zuverlässig ist wie ein Speicherinterface (als Beispiel) beim PC.
Also m.W. ist das Speicherinterface differentiell, hat Push-Pull-Stufen 
und ist perfekt gelayoutet. Das ist schonmal ne ganz andere Nummer als 
die typischen verwaschenen Flanken von I²C. Und bei wichtigen 
Anwendungen verlässt man sich ja doch eben nicht drauf. Bei der 
Software-Entwicklung macht man es sich ganz schön leicht wenn man sagt 
"die Hardware passt schon" ;-)

Frank M. schrieb:
> Ist bei mir noch nicht aufgetreten.
Da hatte ich schon jede Menge Probleme mit... Wenn man eine 
störungsreiche Umgebung (z.B. Fahrzeug) hat kann man viel "Spaß" mit 
sowas haben.

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ein Lochrasteraufbau ist so eine Sache... ist schließlich ein 
Bastelprojekt. Kuperkabel, ca 3-4cm lang kreuz und quer. I2C ist wie SPI 
ein Platinenbus über kurze Strecken, wäre er länger wäre es zb ein LIN 
BUS, der deutlich robuster ist, jedoch physikalisch ähnlich wie I2C 
funktioniert und logisch wie  RS232.

Mit Störungen muss immer gerechnet werden. Ich vermute grob geschätzt, 
dass von den rund 260.000 Lesezugriffen in 3 Tagen, nämlich jede Sekunde 
einer irgendeiner faul ist. Das ist immer noch eine verschwindend kleine 
Fehlerrate.

Die Idee das EE mit einem Pin zu versorgen hatte ich auch schon, nur 
sind es 3.3V, reicht nicht. Und ein Mosfet gibt es nicht, der 3.3V 
schaltet, nur einer dieser Steine mit eingebauter Ladungspumpe.

Die Idee mit dem 9 Mal bimmeln stammt aus einer AppNote von Microchip, 
die die mal rausgegeben haben. Auf den Seite den I2C Konsortiums finden 
sich auch Hinweise, allerdings dieser nicht. Nur dass I2C Hardware mit 
einem reset versehen werden kann durch Strom-Wegnehmen.

: Bearbeitet durch User
Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nein, habe ich nicht, aber das werde ich mal testen. Ich bin damals mal
> lediglich in die Busy-Flag-Falle getippt, als ich die ersten Versuche
> mit STM32 und I2C machte.

Kannst Du das mit dem Busy mal beschreiben? Ich papp mal meinen Code 
dran... der ist eigentlich schon "totoptimiert".

Autor: Strippe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

dieses Problem kommt auch mir bekannt vor. Busy Bit...oder sagen wir: 
Stress Bit. >:->

Vllt mein Beitrag, so ich mich noch erinnere...

Hier wurde ja schon einiges genannt. Timeout, halbwegs vernünftige 
Verdrahtung. Aber eines hattet Ihr noch nicht genannt. Man kann das 
EPROM neu starten. Dafür gibt's es eine Prozedur. Siehe AN1471 von ST, 
"What happens to the M24xxx I²C EEPROM if the I²C bus communication is 
stopped?".

Soweit ich mich weiter erinnere, habe ich den I2C Controller als letzte 
Option doch vom Netz genommen und direkt via GPIO dies durchgeführt.

Und zumindest bei den ST EEPROM steht auch im DB, dass die sich intern 
erst mal vom Netz hängen, wenn sie mit Schreiben noch nicht fertig sind. 
Das kriegt man dann aber über den Timeout hin. Man lässt ihn mehr als 
ein mal ablaufen und sendet nach jeden Timerablauf eine  START condition 
in Erwartung des ACK. Damit bügelt man schon einiges weg.

MfG

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strippe schrieb:
> Soweit ich mich weiter erinnere, habe ich den I2C Controller als letzte
> Option doch vom Netz genommen und direkt via GPIO dies durchgeführt.
>
> Und zumindest bei den ST EEPROM steht auch im DB, dass die sich intern
> erst mal vom Netz hängen, wenn sie mit Schreiben noch nicht fertig sind.
> Das kriegt man dann aber über den Timeout hin. Man lässt ihn mehr als
> ein mal ablaufen und sendet nach jeden Timerablauf eine  START condition
> in Erwartung des ACK. Damit bügelt man schon einiges weg.

Also irgendwie müsstest Du diesen Text mal in Deutsche übersetzen. Vom 
Netz? Steckdose? Und ein EE was schreibt ist tot, blind und merkt gar 
nichts. Daher ballert man ja Starts drauf, erst wenn es ACK'ed ist es 
wieder frei und kann weiter Daten schlucken.

 /* Warte bis I2C Interface frei */
    while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY));

    /* ACK ein */
    I2C_AcknowledgeConfig(I2C_KANAL, ENABLE);

    /* Wenn das E2PROM noch in einem Schreibzyklus ist muss die Start
       Bedingung so oft wiederholt werden, bis es antwortet */

    do {
        /* Erzeuge START Bedingung */
        if (i2c_start() == ERROR)
            return ERROR;
        if (I2C_WaitForEvent(200, I2C_EVENT_MASTER_MODE_SELECT) != SUCCESS)
            return ERROR;
        // Adressiere das E2PROM
        I2C_Send7bitAddress(I2C_KANAL, EE, I2C_Direction_Transmitter);
     } while (I2C_WaitForEvent(200, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) != SUCCESS);

    /* Adresse als 2 x 8 Bit senden */
    if (!i2c_transmit(adr>>8))
        return ERROR;
    if (!i2c_transmit(adr))
        return ERROR;

    /* Sende Datum */
    if (!i2c_transmit(data))
        return ERROR;

    /* Sende I2C3 STOP Condition */
    if (!i2c_stop())
        return ERROR;

: Bearbeitet durch User
Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch bei mir hat der Anschluss eines i2c-LCDs an stm32f103  aus mir bis 
heute unerfindlichen Gründen per hw-i2c nicht geklappt. Prima 
funktioniert hat es dann mit sw-I2c. Ist auch nicht viel langsamer. So 
kann man jedenfalls testen, ob die Hardware in Ordnung ist.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> von den rund 260.000 Lesezugriffen in 3 Tagen, nämlich jede Sekunde
> einer irgendeiner faul ist.

3 Tagen haben ungefähr 260.000 Sekunden.

> Das ist immer noch eine verschwindend kleine Fehlerrate.

Nein, das ist ungefähr 100% Fehlerrate.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris J. schrieb:
> Kannst Du das mit dem Busy mal beschreiben? Ich papp mal meinen Code
> dran... der ist eigentlich schon "totoptimiert".

Der Test ist in Deinem Source zumindest in der Funktion 
EE_TestDevice(uint8_t eeno) drin:
    while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY));

Die Abfrage passiert hier vor jedem I2C-IO. Das ist hier in Ordnung so. 
Dasselbe gilt auch für die Write-Funktionen EE_WriteDataSet() und 
EE_WriteByte(). Auch bei der Funktion EE_ReadByte() ist sie drin.

Aber in der Funktion EE_ReadDataSet() scheint diese Abfrage zu fehlen, 
jedenfalls sehe ich sie auch beim zweiten Hingucken nicht. Stattdessen 
findet man hier einen ominösen delay-Aufruf. Das kommt mir sehr spanisch 
vor. Delays sollte man immer hinterfragen.

An der Stelle solltest Du nachbessern, zumindest die obige Busy-Abfrage 
hinter den delay-Aufruf - also vor den i2c_init()-Aufruf setzen.

: Bearbeitet durch Moderator
Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Aber in der Funktion EE_ReadDataSet() scheint diese Abfrage zu fehlen,
> jedenfalls sehe ich sie auch beim zweiten Hingucken nicht. Stattdessen
> findet man hier einen ominösen delay-Aufruf. Das kommt mir sehr spanisch
> vor. Delays sollte man immer hinterfragen.

Du meinst das hier? Das steht deshalb drin, weil der letzte 
Schreibzugriff nicht "delayed" wird, d.h. die CPU wartet nicht, bis er 
abgeschlossen ist, sondern rennt weiter. Und wenn dann direkt ein 
Lesezugriff kommt reagiert das EE nicht auf die Start Condition. Das 
kann auch ein Busy Bit nicht erkennen, für die CPU ist der Vorgang 
abgeschlossen. Schreibe ich aber fortlaufend findet die Prüfung bei 
jedem neuen Eintritt in die Routine statt.

Ich hab die Routinen mit einem Test umgeben, der mir alle denkbaren 
Möglichkeiten erzeugte, alles durcheinander zu benutzen und nachher zu 
vergleichen. Dabei fiel mir das so auf. Im LA wurde die typische 
Schreibzeit mit 3,2ms gemessen, da sind 4ms halt "grosszügig."

Das Ganze ist halt nur sowas wie auf dem Bild, typischer 
Lötrasteraufbau....

/* Nach vorherigem Schreibzugriff warten */
    if (f_lastwrite) {
        DelayMs(4);
        f_lastwrite = 0;
    }

: Bearbeitet durch User
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris J. schrieb:
> /* Nach vorherigem Schreibzugriff warten */
>     if (f_lastwrite) {
>         DelayMs(4);
>         f_lastwrite = 0;
>     }

Dann setze doch mal die Zeile
 while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY));

genau darunter.

Autor: Karl K. (leluno)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Ist allerdings nicht so wie bei einer Soft I2C,

Hast du das ganze mal mit Soft I2C probiert? Bei dem Projekt dürften ein 
paar ms mehr doch kein Problem sein.

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Hast du das ganze mal mit Soft I2C probiert?

Ist ne Glaubensfrage: Bei einem Hobbyprojekt geht es ja grad darum die 
Hardware auszureizen, da ist der Weg das Ziel. Ich will ja wissen wie 
das alles da drin funktioniert :-)

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Dann setze doch mal die Zeile while (I2C_GetFlagStatus(I2C1,
> I2C_FLAG_BUSY));
>
> genau darunter.

Frank, das ist nicht richtig. Es geht nicht darum, dass die I2C Prime 
Cell fertig ist, sondern das EEPROM. Es gibt keinen Indikator dafür, es 
reagiert einfach nicht. Sobald das STOP kommt geht es in den Write Mode 
und solange ist es taubstumm.

Alles ok :-)

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris J. schrieb:
> Es gibt keinen Indikator dafür, es reagiert einfach nicht.

Doch, und genau das ist der Lösungsweg. Ich zitiere aus dem
Datenblatt des AT24C128 für den Schreibvorgang:

-----------------------------------------------------------
ACKNOWLEDGE POLLING: Once the internally-timed write cycle
has started and the EEPROM inputs are disabled, acknowledge
polling can be initiated. This involves sending a start
condition followed by the device address word. The
read/write select bit is representative of the operation
desired. Only if the internal write cycle has completed will
the EEPROM respond with a zero, allowing the read or write
sequence to continue.
-----------------------------------------------------------

Man wartet nach dem Schreiben eines Blocks solange bis das
EEPROM ein Acknowledge liefert, dann ist es fertig mit
seiner internen Maschinerie.

So "einfach" ist das.

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guckst Du hier :-)

Kann sein, dass ich da noch etwas "unschön" habe, da ich vor dem 
Schreiben abfrage, ob es fertig ist. Im LA sieht das alles schon ganz 
schnuckelig aus.
Das Problem trat ja nur auf, wenn Schreiben und Lesen im Wechsel 
erfolgten.

Das Blöde ist immer, dass man sich nicht traut etwas anzufassen was ja 
funktioniert. Selbst die Abstürze habe ich jetzt im Griff durch das 
"klingeln" und resetten der Hardware + Watchdog. Irgendwann fängt es 
sich wieder und es geht weiter. 4.7kOhm für 2 EEPROMs bei 100khz. 400khz 
gehen auch, jedenfalls im Debugger aber .... naja, lieber etwas weniger 
Gas, dafür auch weniger Unfälle.

Dieser kleine STM32F103 auf dem 2,50 Euro Board ist jedenfalls eine 
schweinegeile Maschine für "Physical Computing", für alles andere nehme 
ich lieber F429.
* Wenn das E2PROM noch in einem Schreibzyklus ist muss die Start
       Bedingung so oft wiederholt werden, bis es antwortet */

    do {
        /* Erzeuge START Bedingung */
        if (i2c_start() == ERROR)
            return ERROR;
        if (I2C_WaitForEvent(200, I2C_EVENT_MASTER_MODE_SELECT) != SUCCESS)
            return ERROR;
        // Adressiere das E2PROM
        I2C_Send7bitAddress(I2C_KANAL, EE, I2C_Direction_Transmitter);
     } while (I2C_WaitForEvent(200, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) != SUCCESS);

: Bearbeitet durch User
Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris J. schrieb:
> * Wenn das E2PROM noch in einem Schreibzyklus ist muss die Start
>        Bedingung so oft wiederholt werden, bis es antwortet */

Nein, eine Start-Bedingung zu senden reicht nicht, siehe
mein Zitat.

Es muss die Adresse des EEPROMs gesendet werden und das
(irgendwann) darauf folgende ACK gilt als Bestätigung dass
das EEPROM wieder frei ist.

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Nein, eine Start-Bedingung zu senden reicht nicht, siehe
> mein Zitat.

Das steckt im

/ Adressiere das E2PROM
        I2C_Send7bitAddress(I2C_KANAL, EE, I2C_Direction_Transmitter);

mit drin. Das ist eine Statemachine, die Zieladresse ist bereits 
dauerhaft hinterlegt. Da ist eine etwas andere Denke nötig, da diese SM 
nur angestossen wird und dann von allein läuft, während die CPU weiter 
rennt. Nur an den Events, die alle interruptfähig sind kann sie 
erkennen, dass was passiert ist.

: Bearbeitet durch User
Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris J. schrieb:
> do {
>         /* Erzeuge START Bedingung */
>         if (i2c_start() == ERROR)
>             return ERROR;
>         if (I2C_WaitForEvent(200, I2C_EVENT_MASTER_MODE_SELECT) != SUCCESS)
>            return ERROR;

Du springst ja schon mit Error heraus bevor du die Adresse
sendest. Allerdings weisss ich nicht genau welche
Fehlerbedingungen bei dir dazu führen ....

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Du springst ja schon mit Error heraus bevor du die Adresse
> sendest. Allerdings weisss ich nicht genau welche
> Fehlerbedingungen bei dir dazu führen

Das ist das EV5. Die SM gibt einen Start auf den Bus und guckt, ob 
dieser überhaupt frei ist, d.h. SDA = high. Ist er es nicht, kommt das 
EV5 nicht und man muss einen Timeout einleiten. Es ist schwierig zu 
unterscheiden welcher der beiden Teilnehmer die Events auslöst. Ich bin 
da auch noch nicht ganz durchgedrungen.

Du könntest aber recht haben.... ich muss das mal in Ruhe mit dem LA 
anschauen, jetzt gehts erstmal auf den Modellflugplatz bei dem Wetter. 
Ist eher was für Regentage.

Auf dem LA Diagramm war allerdings in einer testanwendung, die viele 
Bytes per Pagewrite wegschrieb eindeutig zu sehen, dass erst so 3-4 
Starts kommen im Abstand von 0,5ms und dann die Antwort nach ca 3,2ms. 
Das war also alles richtig, daher habe ich es so gelassen. 
Möglicherweise nochmal drüber nachdenken und nachmessen.

/* ----- Erzeuge Start Bedingung ------ */
static uint8_t i2c_start()
{
   int timeout = I2C_TIMEOUT;

   I2C_GenerateSTART(I2C_KANAL, ENABLE);
   /* Warte auf I2C EV5. Bus frei, Start akzeptiert */
   while (!I2C_CheckEvent(I2C_KANAL, I2C_EVENT_MASTER_MODE_SELECT))
   {
       if (!(--timeout))
        return ERROR;
   }

   return SUCCESS;
}



: Bearbeitet durch User
Autor: Hans-Georg Lehnard (h-g-l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Chris J. schrieb:
>> Wo genau weiss ich nicht
>
> Ich weiss es auch nicht, aber ich bin mir ziemlich sicher
> dass dein (mieser) Hardware-Aufbau schuld ist.
>
> Aber daran kann es ja nach deiner Auffassung sicherlich
> nicht liegen. Es ist immer der Hersteller eines Chips oder
> der fehlerhafte Compiler dran schuld.

Aber es kommt vor ;-)

Some Cortex-M3 cores can cause data corruption when ldrd instructions 
with overlapping destination and base registers are used. This option 
avoids generating these instructions. This option is enabled by default 
when -mcpu=cortex-m3 is specified.

@Christian

wenn du den GCC benutzt setze mal -mcpu=cortex-m3

Das bewirkt machmal Wunder bei der HW SPI und dem busy Bit;-)

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hans-Georg L. schrieb:
> wenn du den GCC benutzt setze mal -mcpu=cortex-m3
>
> Das bewirkt machmal Wunder bei der HW SPI und dem busy Bit;-

Autor: Hans-Georg Lehnard (h-g-l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann probier mal für Spass den Fix direkt zu setzen ...

-mfix-cortex-m3-ldrd

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-mfix-cortex-m3-ldrd
Some Cortex-M3 cores can cause data corruption when ldrd instructions 
with overlapping destination and base registers are used. This option 
avoids generating these instructions. This option is enabled by default 
when -mcpu=cortex-m3 is specified.

https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/ARM-O...

: Bearbeitet durch User
Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. schrieb:
> Ich benutze die I2C Hardware des Chips, frage Fehler
> "meistens" ab aber nicht hinter jedem einzelnen Befehl

Das ist bei HW-I2C aber Pflicht.
Z.B. nach NACK auf Adresse/Daten wird Dir das HW-I2C was husten, wenn Du 
weitere Daten in das Senderegister schreibst.

Hier mal ein einfaches SW-I2C (AVR):

https://www.mikrocontroller.net/attachment/119775/xeeprom.c


Christian J. schrieb:
> Ist allerdings nicht so wie bei einer Soft I2C, dass man mal eben an den
> Pins wackeln kann

Nach I2C-Disable sind die Pins wieder normale IOs.

Autor: Chris J. (Firma: privat) (chris_urbex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
N'Abeeeend,

ich habe die Ursache für das Aufhängen des EE's gefunden, was ja 
sporadisch aber doch regelmässig auftrat.

Es lag an den vielen Ints, die bei mir rumfleuchen und von denen zb der 
des RF Moduls oder die Bespielung der HC595 Kette mit 6 Bausteinen recht 
lange dauern kann. Seitdem ist nun seit 3 Tagen Ruhe im Karton. 
Sicherheitshalber habe ich alle Kommandos gekapselt, auch wenn einige es 
vielleicht nicht brauchen.
static uint8_t i2c_receive_nack()
{
    unsigned int timeout = I2C_TIMEOUT;

    // ACK bei empfangenen Daten abschalten
    __disable_irq();
    I2C_AcknowledgeConfig(I2C_KANAL, DISABLE);
    // Warte fuer EV7 = Daten sind empfangen worden
    while (!I2C_CheckEvent(I2C_KANAL, I2C_EVENT_MASTER_BYTE_RECEIVED))
    {
       if (!(--timeout)) {
            __enable_irq();
            return ERROR;
       }
    }

    // Stop direkt danach erzeugen
    I2C_GenerateSTOP(I2C_KANAL, ENABLE);
    timeout = I2C_TIMEOUT;
    while (!I2C_CheckEvent(I2C_KANAL, I2C_EVENT_MASTER_BYTE_RECEIVED))
    {
       if (!(--timeout)) {
            __enable_irq();
            return ERROR;
       }
    }

    // Read and return data byte from I2C data register
    uint8_t byte = I2C_ReceiveData(I2C_KANAL);
    __enable_irq();
    return byte;
}

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.