Forum: Mikrocontroller und Digitale Elektronik sich aufhängende Sensoren LM70/75?


von Stefan W. (wswbln)


Lesenswert?

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

von Haku (Gast)


Lesenswert?

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.

von Stefan W. (wswbln)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von Stefan W. (wswbln)


Lesenswert?

Hihi: es sind keine "Bastlerkreise" und der Bus bleibt daher schön 
onBoard (insgesamt mit allen Layout-Schnörkeln vielleicht 20cm 
(Europakarte))

von Peter D. (peda)


Lesenswert?

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

von Stefan W. (wswbln)


Lesenswert?

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.

von Michael U. (amiga)


Lesenswert?

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

von Oliver N. (nixo2)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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

von Michael U. (amiga)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Stefan W. (wswbln)


Lesenswert?

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

von Stefan W. (wswbln)


Lesenswert?

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.

von Gerhard. (Gast)


Lesenswert?

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

von Gerhard. (Gast)


Lesenswert?

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

von Stefan W. (wswbln)


Lesenswert?

Ja, sowas in der Art soll es dann irgendwann mit LM75-kompatiblem 
Befehls-/Registersatz geben.

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
Noch kein Account? Hier anmelden.