Hi Leute, ich habe in letzter Zeit einige Probleme mit den National Semiconductor Temperatursensoren LM70 (SPI) und LM75 (I²C), welche sich bei den EMV-Tests (Burst und Surge) "aufhängen". Beim LM75 ist besonders ärgerlich, dass dieser dann den I²C Bus blockiert indem er SDA und/oder SCL auf low zieht, der LM70 dagegen antwortet einfach nicht mehr. Man bekommt die Chips nur duch Ab- und Wiederanschalten der Versorgungsspannung aus diesem Zustand heraus. Den steuernden AVRs bzw. STR912-ern machen die (Rest-)Störungen dagegen nichts aus. Hat jemand mit diesen Chips ähnliche Erfahrungen gemacht? Tipps für Abhilfe (außer noch besserem Schutz vor Burst/Surge an den Eingangsleitungen des Gerätes - das geht leider erst im PCB-Redesign)? Stefan
Sicher dass der Chip sich aufhängt? Ich hatte ein ähnliches Phänoment einmal bei einem Bus mit einer handvoll Portexpandern. Nach einiger Zeit ging dann plötzlich garnix mehr. Des Rätsels Lösung: Bei der Übertragung ist "irgendwann" mal ein Takt (SCK) flöten gegangen, danach hat dann eben nix mehr gestimmt, weil z.B. die Bestätigungen (ACK) ausblieben. Ausweg: vernünftig programmieren und beim geringsten Zweifel den Bus mal auf Idle legen, damit die Chips von vorne anfangen zu zählen.
Ja, ich bin mir ziemlich sicher: ohne die Störbeaufschlagung laufen die Boards wochenlang problemlos. Treten die Abstürze auf, helfen auch die üblichen I²C-Recoveryversuche (SCKs generieren, bis der Arzt kommt bzw. der Bus wieder released wird) nichts. Die Störungen treten auch nicht auf, wenn man die SDA bzw. MISO) Pins der Sensoren hochbiegt und diese somit vom Bus nimmt. Die am selben Bus befindlichen Portexpander (PCA9535) laufen dann auch während der Burst/Surge-Störbeeinflussung problemlos.
Wie lang ist denn der I2C-Bus? Auch wenn es in Bastlerkreisen sehr gerne gemacht wird, der I2C ist nicht dafür vorgesehen, das Geräteinnere zu verlassen. Bzw. dann sollte man wenigstens Bustreiber auf beiden Seiten verwenden (P82B715). Peter
Hihi: es sind keine "Bastlerkreise" und der Bus bleibt daher schön onBoard (insgesamt mit allen Layout-Schnörkeln vielleicht 20cm (Europakarte))
Stefan Wimmer wrote: > Beim LM75 ist besonders > ärgerlich, dass dieser dann den I²C Bus blockiert indem er SDA und/oder > SCL auf low zieht Das ist aber seltsam. Ich kenne es eigentlich so, daß bei I2C-Slaves (24Cxx, PCF8574 usw.) der SCL nur Input ist, d.h. rein schaltungstechnisch kann er SCL gar nicht auf low ziehen. Kommt das SCL = low wirklich vom Sensor? Peter
Ups, damit (SCL = Eingang bei Slaves) hast Du natürlich recht. Da waren die Finger schneller als das Hirn... ;-) Es ist SDA, welches auf Low bleibt und somit den Bus lahmlegt.
Hallo, das stimmt so nicht. Ein I2C-Slave darf SCL auf Low halten, das zwingt den Master zum Warten, wenn der Slave wegen interner Beschäftigung die Daten nicht so schnell entgegen nehmen kann. Gruß aus Berlin Michael
So ist es auch meiner Meinung nach korrekt, die Slaves können den Takt so verlangsamen, wenn Sie mit der Geschwindigkeit nicht mehr mitkommen, indem sie SCL einfach verlängern. Der Master muss darauf überprüfen.
@ Michael U. (amiga) >das stimmt so nicht. Ein I2C-Slave darf SCL auf Low halten, das zwingt >den Master zum Warten, wenn der Slave wegen interner Beschäftigung die >Daten nicht so schnell entgegen nehmen kann. Richtig, er darf das machen, muss aber nicht. Viele ICs machen von der Option keinen Gebrauch. Mfg Falk
Hallo, @Falk Brunner (falk): bezog sich vorrangig auf das Posting von Peter Dannegger (peda) von 05.02.2008 19:05. Bei I2C sind beide Leitungen nie reine Eingänge, auch beim Slave nicht. Diese Wait-Geschichte hat mich mal beim MAS3507D genervt, Atmels alte AppNote zu I2C hat genau das nicht berücksichtigt und irgendwann hing der Krempel dann immer fest. Beim konkreten Problem des Posters wird es aber vermutlich nicht viel weiterhelfen, leider. Gruß aus Berlin Michael
Stefan Wimmer wrote:
> Es ist SDA, welches auf Low bleibt und somit den Bus lahmlegt.
Und ein Reset des I2C-Busses hilft nicht?
D.h. bis zu 9-mal SCL mit 100kHz takten und STOP senden.
Dazu muß natürlich das HW-I2C erst disabled werden und dann die Pins
selber takten.
Ich nehme ja immer SW-I2C, wenn der MC single-Master ist.
Dann muß man nicht drauf achten, ob sich das HW-I2C intern verhakt
(Timeout) und es resetten (stoppen, disablen, Interuptflag löschen,
enablen).
Irgendwie blöd, daß man bei nem HW-I2C die interne Statusmaschine nicht
auslesen kann.
Man kriegt immer erst einen Status, wenn eine Aktion durchgelaufen ist.
Wenns hängt, weiß man also nicht, warum.
Peter
Michael U. wrote: > Hallo, > > @Falk Brunner (falk): > bezog sich vorrangig auf das Posting von Peter Dannegger (peda) von > 05.02.2008 19:05. > > Bei I2C sind beide Leitungen nie reine Eingänge, auch beim Slave nicht. Guck erstmal ins Datenblatt, ehe Du solchen Unsinn behauptest. Da steht eindeutig: Input Die meisten Slaves haben nur einen SCL-Input (24Cxx, PCF8574 usw.). Wozu sollten sie auch den Master warten lassen? Ich hab ja nirgends behauptet, daß alle Slaves so sind, es mag also Ausnahmen geben. Peter
Hi Leute, danke für die angeregte Diskussion - auf diese Weise bekommt man ja oft neue Denkanstöße. Also wir haben beides probiert: sowohl Hardware- als auch Soft-I²C. Bei beiden bekommt man den aufgehängten Sensor nicht mehr aus dem Zustand heraus, wo er SDA auf low hält. Auch mit noch so vielen SCKs nicht. Und solange er SDA nicht loslässt kann man auch keine Stop-Bedingung erzeugen. Ich habe auf einem Board versuchsweise mal einen TP0101T (P-Channel MOSFET) in die Versorgungsleitung des LM75 "eingefädelt" und wenn ich damit einen Power-Cycle mache, fängt der Sensor sich wieder. Aber das kann ja wohl nicht die Lösung sein! Grüße aus Berlin-Tempelhof, Stefan
Hi Leute, ich wärme den Thread mal nochmal auf, denn es scheint so, als ob ich nicht der einzige bin, der Probleme mit den LM75 hat, denn National hat den Chip verbessert und bietet ihn nun mit Filtern in SDA und SCL an. Maxim geht noch einen Schritt weiter und kündigt gerade ein LM75-kompatibles Derivat mit I²C Watchdog an. Mal sehen, ob und wann das matrialisiert. Dann werde ich damit ein paar Burst-Tests machen.
Habe zum Thema eine interessannte Application Note gefunden: http://www.maxim-ic.com/appnotes.cfm/appnote_number/476 Die SMB Varianten scheinen robuster zu sein - Angeblich;-) Gruss, Gerhard
Hier ist noch was Llesenswertes: http://www.electronicsweekly.com/products/2004/08/18/1619/temperature-sensor-uses-i2c.htm In diesem Artikel steht dass beim MAX5700 eine Bus Reset Leitung vorhanden ist um den Bus im FAlle eises Lock-up wieder frei zu bekommen. Ist doch ulkig?-) Gruss, Gerhard
Bitte 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.