Moin, ich teile dann mal meine Erkenntnisse :-) Nachdem ich da mehrere Tage intensive Tests habe laufen lassen und 2 Atmel 64k EE's geopfert habe, die einige Millionen Random Zugriffe gemacht haben, Schreiben und Lesen per Pagewrite im zufälligen Wechsel, wieder und wieder rund um die Uhr. Einwandfreies Design ist vorausgesetzt, kurze Leitungen, 100Khz statt 400khz (auch wenn es geht), ausreichende Pull Ups (4.7K bei mir), dazu 100nF Blocker an dem EE. Es reicht ein einziger Störpuls aus, damit die beiden Statemachines des uC und des EE aus dem Takt kommen. 1. Auch wenn das Datenblatt es zulässt ein EE mit 3,3V zu betreiben: Mit 5V (Vcc und Pull Ups an 5V) geht es deutlich stabiler! Mit 3.3V trat es trotzdem noch 2 Mal bei den Tests auf. 2. Ein "hängender I2C Bus" bei einem STM32 ist nicht mehr zu resetten, da habe ich alles Denkbare versucht, sowhl die I2C hardware des STM32 zu resetten als auch das "klingeln" an der SCL Leitung. 3. Es müssen ZWINGEND während der Buskommunikation alle zeitintensiven Ints unterbunden werden! Mag sein, dass es da Lücken gibt, wo es geht, zb nach dem Startbit und vor der Adressierung aber erst seit ich bei den Zugriffen totale Stille einkehren liess läuft es seit nunmehr 3 Tagen durch. 4. Einwandfreie Software, die jeden Fehler der Event Flags abfängt und dann direkt STOP sendet und den Bus freigibt. Tiefer wollte ich da nicht mehr einsteigen, vielleicht hilft es ja jemandem... Gruss, Christian
Für mich klingt das nach einem einem Klaren Votum für Soft I²C.
Meine Geraete sind meist Kleinserien (so 100 bis 1.000 St.), die aber meist über 10 Jahre im Betrieb sind. Der Spitzenreiter liegt z.Zt. bei 15 Jahren. Ich persönlich benutze nur Soft-I2C: einschalten und vergessen. Ehrlich gesagt habe ich Mühe zu verstehen, warum man wegen ein paar lahmen ICs, die da angebunden werden müssen, sich mit der HW-Implementierung herumschlaegt.
Chris J. schrieb: > 3. Es müssen ZWINGEND während der Buskommunikation alle zeitintensiven > Ints unterbunden werden! Ich habe auch Deinen anderen Thread dazu gelesen. Auch dort waren scheinbar irgendwelche Nicht-I2C-Interrupts die Ursache dafür, dass sich die I2C-Peripherie aufhing. Aber ich verstehe das nicht: I2C arbeitet synchron mit einer Clock, warum sollen da irgendwelche Interrupts (wenn sie korrekt programmiert sind), den I2C-Bus zum Hangup bringen? Wenn irgendwelche "zeitintensive" Interrupts die Flanke von Data oder Clock etwas verzögern, was solls? Der STM32 bestimmt den Takt! Lass ihn doch um mehrere msec jittern, das tut dem Master (und auch dem Slave) nicht weh. Also: Mir fehlt eine einleuchtende Begründung, warum ich das tun sollte.
:
Bearbeitet durch Moderator
Mehmet K. schrieb: > Ehrlich gesagt habe ich Mühe zu verstehen, warum man wegen ein paar > lahmen ICs, die da angebunden werden müssen, sich mit der > HW-Implementierung herumschlaegt. z.B. wenn der Controller noch was anderes zu tun hat als tausende Takte in den Warteschleifen für Soft I2C zu hängen! Frank M. schrieb: > Aber ich verstehe das nicht: I2C arbeitet synchron Ganz genau... man bräuchte ein LA/Oszilloskop Bild vom Problem. Man kann ja im Fehler Fall einen Ausgang setzen und darauf triggern.
Frank M. schrieb: > I2C arbeitet synchron mit einer Clock, > warum sollen da irgendwelche Interrupts (wenn sie korrekt programmiert > sind), den I2C-Bus zum Hangup bringen? Ich habe jetzt nicht mitbekommen, welcher STM32 gemeint ist. STM32F4xx hat einen ellenlangen Eintrag zu I2C im Errata Sheet, STM32F10x immerhin auch zwei Seiten in Bezug auf Wechselwirkung mit anderen IRQs.
Frank M. schrieb: > Aber ich verstehe das nicht: I2C arbeitet synchron mit einer Clock, > warum sollen da irgendwelche Interrupts (wenn sie korrekt programmiert > sind), den I2C-Bus zum Hangup bringen? Wenn irgendwelche "zeitintensive" > Interrupts die Flanke von Data oder Clock etwas verzögern, was solls? > Der STM32 bestimmt den Takt! Lass ihn doch um mehrere msec jittern, das > tut dem Master (und auch dem Slave) nicht weh. > > Also: Mir fehlt eine einleuchtende Begründung, warum ich das tun sollte. Das wäre eine Begründung: Walter T. schrieb: > Ich habe jetzt nicht mitbekommen, welcher STM32 gemeint ist. STM32F4xx > hat einen ellenlangen Eintrag zu I2C im Errata Sheet, STM32F10x immerhin > auch zwei Seiten in Bezug auf Wechselwirkung mit anderen IRQs. Also geht es hier um Workarounds für Bugs in den Chips und nicht wirklich um I2C. Ein extremer Workaround ist alles in SW zu machen. MfG Klaus
Chris J. schrieb: > ich teile dann mal meine Erkenntnisse :-) Nachdem ich da mehrere Tage > intensive Tests habe laufen lassen Mich hat es einige Minuten gekostet Errata von ST zu finden und den vorgeschlagenen Fix per copy&paste einzufügen. Chris J. schrieb: > Ein "hängender I2C Bus" bei einem STM32 ist nicht mehr zu resetten, > da habe ich alles Denkbare versucht, sowhl die I2C hardware des STM32 zu > resetten als auch das "klingeln" an der SCL Leitung. Das ist auch Quatsch!
♪Geist schrieb: > Mich hat es einige Minuten gekostet Errata von ST zu finden und den > vorgeschlagenen Fix per copy&paste einzufügen. Welcher war das? Ich habe mir gerade mal das "STM32F40x and STM32F41x Errata sheet" vom Juli 2017 angeschaut und finde im Kapitel "2.4 I2C peripheral limitations" nichts bzgl. Problemen mit anderen Interrupts.
Frank M. schrieb: > Aber ich verstehe das nicht: I2C arbeitet synchron mit einer Clock, > warum sollen da irgendwelche Interrupts (wenn sie korrekt programmiert > sind), den I2C-Bus zum Hangup bringen? Wenn irgendwelche "zeitintensive" > Interrupts die Flanke von Data oder Clock etwas verzögern, was solls? > Der STM32 bestimmt den Takt! Lass ihn doch um mehrere msec jittern, das > tut dem Master (und auch dem Slave) nicht weh Ich habe zu Hause mit Bordmitteln gearbeitet und nach Veränderungen jeweils Test laufen lassen. Dazu gegoogelt und einen Beitrag gefunden, dass bestimmte Flags unbedingt atomar bearbeitet werden müssen, zb das EV_6 Flag. Es gibt sicherlich viele Lücken, wo Ints laufen können aber dazu müsste ich viele neue Tests machen und dazu fehlt mir etwas der Nerv. Mir flackert auch etwas die Anzeige, da die PWM Ints nicht durchkommen, ggf. schraube ich da noch etwas herum. In diesem Fall ist die Soft I2C sicherlich besser, da die Hardware nunmal echt komplex ist. Für so eine einfache Sache viel zu aufwendig. Da bin ich auch reingefallen: Errata sheet: When the EV7, EV7_1, EV6_1, EV6_3, EV2, EV8, and EV3 events are not managed before the current byte is being transferred, problems may be encountered such as receiving an extra byte, reading the same data twice or missing data. Deswegen INT Sperren: Workaround 2 Use I2C interrupts and boost their priorities to the highest one in the application to make them uninterruptible Wurde in den SpdPeriph Libs bereits durch ST behoben: Workaround 3 (only for EV6_1 and EV6_3 events used in method 2) EV6_1 event (used in master receiver 2 bytes): Stretch SCL line between ADDR bit is cleared and ACK is cleared: a) ADDR=1 b) Configure SCL I/O as GPIO open-drain output low c) Clear ADDR by reading SR1 register followed by reading SR3
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.