mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik EMV-Problematik


Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich  bin gerade (na gut vor drei Stunden) durch Google auf euer Forum 
gestoßen. Erst ein mal großes Lob.

So, nun zu meinem Problem:

Kennt einer von euch irgendwo eine unabhängige Quelle, wo die EMV 
Problematik bzgl. unterschiedlicher Single-Chip Lösungen untersucht 
wurde? Also z.B. Einen Vergleich zwischen AVR und PIC?

Ich habe folgendes Problem:

Ein RS485 Bussystem mit mehreren Controllern funzt beim Endanwender 
nicht so wie es soll.

Jedes System hat eine Adresse, welche nach Auslieferung der Controller 
einmalig (über die RS 485) gesetzt und im EEPROM (PIC16F876) abgelegt 
wird. Das Protokoll dazu ist eigentlich relativ sicher (da hab ich schon 
genug Lehrgeld gezahlt). Das Problem ist  nun, dass anscheinend bei 
einer bestimmten Kundeninstallation (einige andere Kunden haben 
komischerweise das Problem seit Jahren nicht, da funzt alles problemlos) 
sich die im EEPROM gespeicherte Adresse löscht oder ändert.

Das Protokoll ect. Hab ich nun schon mehrere Male gecheckt. Ich kann 
nichts finden, was evtl. dem PIC sagt, das er seine Adresse ändern soll.

Stehe ich nun vor einem EMV-Problem?

Das einzigste, was ich hier gefunden habe ist, das der PIC wesentlich 
störunanfälliger (bzgl. EMV) ist als der AVR.

Der Kunde behauptet nun allerdings, dass es ja generell Probleme mit 
Microchip-EEPROMs und Controllern gibt.? Wahr oder falsch? Mein geGOOGLE 
hat leider keinen Erfolg gebracht.

Für alle Antworten schon mal danke im Voraus.

Mit freundlichen Grüßen
Jörg

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich eigentlich nicht bestätigen. Seit nunmehr 4 Jahren habe ich 
einen PIC-Dimmer am Netz laufen. Sämtlichen Abstimmparameter sind im 
EEPROM abgelegt - kein Problem, kein Absturz in 4 Jahren.

Reiner

Autor: edi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

wie sieht es aus mit abschirmung der kabel , erdung der
gehaeuse bzw anlage.?
abgeschirmte kabel beidseitig an erde..!

ed

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Reiner,

wie gesagt, etliche Anwendungen mit dem selben Controller laufen ohne 
Probleme. Nur EINE Anwendung beim Kunden spinnt irgendwie.

Also klare Sache. Irgendetwas geht schief. Könnten ja auch extreme 
Macken in der Versorgunsspannung sein.

Nur, es ist ein sehr guter Kunde.!

Naja, verlieren will ich den auf keinen Fall. Nur sein Argument, das 
MICROCHIP generell anfällig ist, das kann ich nicht nachvollziehen.

Deswegen suche ich einen unabhängigen Testbericht.

MfG
Jörg

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo edi,

das ist nicht das Problem.

Ich entwickel und programmier Systeme.

Die müssen bei (fast, immer geht nicht) jeder Installstion 
funktionieren. Auch wenn die Inst.- Firma nur billige Kabel verwendet.

Das Problem ist, das ich dem Kunden seine Meinung (PIC ist ja eh 
anfällig) wiederlegen muss.
Daher meine Frage.
MfG
Jörg

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du den deine Schaltung vorher hinreichend auf EMV und ESD getestet 
und entsprechende Prüfprotokolle?

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein Anfälligkeiten kann ich nicht bestätigen, selbst die mittlerweile 
tausende von med. Meßgeräten(mein job) mit PIC's zeigen keine 
Störanfälligkeit. Sei dir sicher unsere Kunden sind da sehr empfindlich 
;)
Reiner

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kenne das Problem, trotz kompletter EMV-Prüfung traten bisweilen 
Probleme mit EEPROMS auf, sporadisch und nicht simulierbar, sowohl beim 
PIC als auch beim AVR.
Wenn du Platz hast, speichere die Daten mehrfach, mit Checksumme. Eine 
kleine Routine am Programmstart kann dann die Gültigkeit des 
EEPROM-Inhalts feststellen, und, falls defekt, wiederherstellen. Löst 
zwar nicht das eigentliche Problem, aber keiner merkt was davon :-)
Niemals gab es Probleme mit externen I2C-EEPROMs, weshalb ich diese 
recht häufig einsetze.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich auch bestätigen. Ich habe früher 8051 mit externen 24C02 
eingesetzt, der läuft und läuft.

Dann mit dem internen EEPROM des AVR gabs Probleme. Ich bin dann auf die 
neuen Typen mit Brown-Out umgestiegen und habe die Daten mehrfach 
gespeichert. So scheint es zu gehen.


Peter

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mikkki,

ja, die hab ich.
Hat ne Menge Geld gekostet. Bei der Prüfung gab es aber keine Probleme 
in dieser Hinsicht.
Mittlerweile haben wir so ca. 3.000 Systeme  (Schaltung und Software 
identisch) verkauft. Die Systeme laufen alle ohne Probleme. Nur gerade 
eine Anwendung bringt Probleme mit sich.
Warum, ????

Bei dem Kunden laufen auch andere Systeme einwandfrei. Nur die eine 
spinnt.
Ich als Entwickler muss nun der Sache auf den Grund gehen. Auch wenn es 
"nur" eine problematische Anwendung ist.

Im Allgeneinen suche ich den Fehler immer erst bei meiner 
Implementation. Ich kann nur dummerweise nichts finden und dann die 
Behauptung des Kunden (die haben auch eine sehr gute 
Entwicklungsabteilung), das eben Microchip generell Probleme hat. Die 
muss ich entweder wiederlegen oder klein beigeben.

Also nochmal die Ursprungsfrage:

Gibt es irgendwo eine Untersuchung bzgl. EMV für unterschiedliche 
Mikrocontroler?

@Reiner

Das ist eigentlich genau die Erfahrung, die ich auch gemacht habe. 
Bisher gab es noch  nie Probleme. Welchen PIC setzt ihr eigentlich ein? 
Ich arbeite größtenteils mit dem 16F876 oder dem 16F628.
MfG
Jörg

PS: Das Forum hier ist Super. Mit so vielen Antworten in der kurzen 
Zeitspanne hab ich gar nicht gerechnet.
Vielen Dank für jede Antwort.

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC16C73, PIC16C74, PIC16C62, PIC16F873, PIC16F876
Reiner

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Reiner
Tja, dann kann es ja wohl doch nur eine EMV-Problematik sein.?!

oder doch nicht?

MfG
Jörg

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wer soll denn da hineinsenden?

Der PIC stört ja nicht andere, sondern wird gestört. Könnte es nicht 
auch Spannungsspitzen auf den Leitungen sein. Irgend welche starken 
magn. Störfelder die in die Leitungen induzieren? Oder eine Sendeanlage 
in der Nähe, Werksfunk etc..

Reiner

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ crazy horse

Also sind die Behauptungen des Kunden doch nicht ganz aus der Luft 
gegriffen. Das mit der doppelten Abspeicherung ist eine gute Idee. 
Speicherplatz ist noch genügend frei. Nur nützt das auch nichts, wenn 
aus irgendeinem Grund der komplette EEPROM gelöscht würde. Ich werde es 
aber trotzdem in dieser Art und Weise implementieren. Die nächste Serie 
des Systems bekommt allerdings wieder die alt bewährten Lötbrücken (bzw. 
Jumper) zur Adresseinstellung. Prinzipiell darf der PIC in der Anwendung 
alles vergessen, nur nicht seine Adresse.

@Reiner
Mit Sicherheit gibt es Probleme entweder mit der Versorgungsspannung 
oder den Datenleitungen. Die größten Probleme hatte ich einmal bei einem 
System, wo 20m daneben der ICE durchdonnerte. Da hab ich nicht einmal 
etwas auf dem Monitor erkannt wenn gerade ein Zug in der Nähe war.

Nochmals Danke für eure schnelle Hilfe.

MfG
Jörg

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich binn es nochmal.

Bzgl. der Gültigkeitsprüfung der gespeicherten Adresse würde ich 
folgenden Weg gehen:

Es wird die Adresse und die invertierte Adresse abgespeichert. Kommt ein 
Befehl über die serielle, wird getestet, ob diese beiden EEPROM-Inhalte 
OK sind. Wenn nicht, hole ich mir die Adresse vom "Backup", welches in 
der gleichen Art und Weise abgelegt ist also normal und invertiert.

Also nutze ich 4 Byte. Auf die ersten zwei wird ständig (bei jeder 
Befehlsauswertung) zugegriffen und diese werden auf Gültigkeit 
überprüft. Wird dabei ein Fehler festgestellt, wird das "Backup" auf 
Gültigkeit überprüft und wenn OK die Adresse wieder hergestellt.

Ob die Bits im EEPROM einfach so umkippen oder evtl. eine Leseopperation 
fälschlicherweise als Schreibopperation erkannt wird kann ja wohl keiner 
sagen. So oder so bringt der vergleich von 2 Byte nichts, da ich ja 
nicht sicher sein kann, das sich nicht evtl. das "Backup" geändert hat.

Soweit OK, oder könnte ich das irgendwie noch sicherer machen?

MfG
Jörg

Autor: mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi

könnte es sein das da jemand versucht an deiner schaltung herumzubasteln 
und die probleme von daher kommen ?

woher hat dein kunde überhaupt die information das die pic's so anfällig 
sind ?

wenn du schon so große stückzahlen deiner schaltung im einsatz hast und 
diese probleme nur bei einem kunden auftreten würde ich mir darüber mal 
gedanken machen


mfg
mike

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde wenn man den Daten mehrfach abspeichert jeden Block mit einer 
eigenen Prüfsumme versehen. Somit ist sehr leicht überprüfbar welcher 
Datenblock noch gültig ist.
Wenn sich die Schaltung den "Müll" über die Versorgungsspannung 
einfängt, schafft evtl. eine externe Reset-Logik Abhilfe. Auch sollte 
man evtl. den RS485 Anschluss überprüfen. Hier sind Potentialdifferenzen 
auf der Masseleitung (Schirm) oder fehlende galvanische Kopplung in 
seltenen Fällen die Störenfriede.

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,
ich verwende den PIC16F84 in einer Steuerung für einen 
Drehstromgenerator (größtmögliches Störfeld) und der läuft dort 
problemlos seit über 2 Jahren. Das ist zwar statistisch nicht relevant, 
zeigt aber das zumindest dieser PIC einiges verträgt. Mit dem HC11 habe 
ich mit dem EEPROM ab und zu auch mal solche ähnlichen  Probleme gehabt. 
Störungen beim Beschreiben von Speichern (und natürlich auch beim 
Auslesen) können nur während der Selektion stattfinden. Es gilt also, 
genau diese Zeit zu minimieren und da haben EEPROM's und Flash's 
schlechte Karten. Für kleine Datenmengen/ Variable usw. benutze ich seit 
Jahren ein FRAM und habe damit solche Probleme ausschalten können. 
Störungen über lange Kabel neben extremen Störquellen lassen sich damit 
allerdings auch nicht verhindern. In Deiner Situation würde ich ein 
Referenzsytem installieren und vergleichen (ohne Meßdaten kommst Du da 
keinen Schritt weiter). Mindestens ein Analogrecorder für 
Leitungsüberwachung ist notwendig.

MfG  Manfred Glahe

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War natürlich ein absoluter Schreibfehler
"fehlende galvanische Kopplung" sollte natürlich "fehlende galvanische 
Trennung" heissen.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sabotage möchte ich erst einmal ausschliesen. Jedoch die Aussage des 
Kunden bzgl. der Störanfälligkeit macht mich auch etwas nachdenklich.

Ich nehme an, das die Probleme von der Versorgungsspannung her rühren. 
Alle Systeme sind an einer Leitung angeschlossen (2xRS485 + 
Spannungsversorgung) und schalten induktive Lasten. Wir empfehlen dem 
Kunden zwar generell die Versorgungsspannung der Controller und die 
Schaltspannung für die induktiven Lasten getrennt bereitzustellen aber 
halten tun die sich so gut wie nie dran. Geht ja meist auch so. Da 
braucht nur mal eine Last ohne Freilaufdiode angeschlossen zu sein. Wenn 
im Extremfall alle Controller einschalten fliesen da schnell mal bis zu 
10A.

Trotz alle dem, der Kunde ist König und die Controller dürfen ihre 
Adresse nicht verlieren, es sei denn der Kunde schlägt mit dem Hammer 
drauf.

Um eine externe Resetlogig werde ich wohl nicht herumkommen. Beim 16F84 
hatten ich z.B. große Probleme bei kurzen Spannungsausfällen. Wenn die 
Spannung auf einen bestimmten Wert fällt verlieren die Register ihren 
Inhalt. Steigt die Spannung wieder an, läuft der PIC irgendwo im 
Programm weiter, wo er evtl. gar nicht hätte hinkommen dürfen z.B. in 
der EEPROM-Schreibroutine. Ein MAX709 hat das Problem dann beseitigt. 
Der intgrierte Brown-Out-detect des 16F876 sollte zwar kurze 
Spannungseinbrüche sauber erkennen aber sicher ist sicher.

Was die RS485 anbetriff, da hab ich auch schon die tollsten Sachen mit 
Reflexionen auf dem Bus erlebt.

MfG
Jörg

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da fällt mir noch etwas ein. Nach Aussage des Kunden betrifft das 
Problem nur Controller, welche er selbst mittels Epoxydharz vergossen 
hat.?

MfG
Jörg

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg,

ist den wirklich immer der komlette EEPROM gelöscht ?

Bei den AVRs ohne Brown-Out waren immer nur einzelne Bytes gelöscht. 
D.h. mit Mehrfachspeicherung konnte ich diese Bytes wieder restaurieren.

Es hatte aber auch nichts mit Störungen zu tun, sondern die 
Datenverluste traten ausschließlich beim Ein- oder Ausschalten auf. Und 
auch dann, wenn gar kein EEPROM-Schreibbefehl im Programm war.


Peter

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir nicht sicher, ob der gesammte EEPROM gelöscht ist. Hoffe mal 
nicht. Da die Controller vergossen sind komm ich auch nicht mehr an die 
Daten ran. Ich kann nur feststellen, was an der einen Stelle steht. 
Finde ich dort ein 0xFF, sieht es nicht so gut aus dann könnte evtl. der 
gesamte EEPROM gelöscht sein.

Die Mehrfachspeicherung habe ich bereits implementiert und werde dem 
Kunden ein paar Muster zum Austausch anbieten.
Dann mal abwarten was sich tut.

Bzgl. des Ein- und Ausschaltens könnte es schon möglich sein, das die 
Versorgung des Systems beim Schalten zusammenbricht. Also ständiges Ein 
und Aus. Wenn der Kunde eine Logdatei fährt sollte sich das aber 
rausbekommen lassen.

MfG
Jörg

Autor: Direx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muss man systematisch suchen:
ich vermute mal, die Störungen kommen durch die Induktivitäten / 
Versorgungsleitung.

Du kannst mal versuchen, das Gerät getrennt zu versorgen.
Spannungen sauber abblocken, evtl. Suppressoren etc. einbauen.
Oder an alle Leitungen Drosseln / Kapazitäten hängen, damit HF draußen 
bleibt.

Du kannst mitzählen, wieoft ein POR oder WDT-Reset ausgeführt wurde, und 
später abfragen.

Ein ähnliches Problem hatte ich auch mal: ein 87C49 hatte eine externe 
RTC58321 (RealTimeClock). Ab und zu änderte sich die Zeit ohne 
ersichtlichen Grund. Ursache war der Spannungsverlauf beim Ein- und 
Ausschalten.

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem mitzählen ist eine gute Idee. Damit hat man schon mal einen 
Anhaltspunkt und der Kunde kann dann selbst testen, ob seine 
Installation halbwegs OK oder das totale EMV-Chaos ist.

Also nochmal vielen Dank für alle Tipps und Hinweise.

MfG
Steffen

Autor: Christian Bischoff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe auch noch eine Idee beizusteuern. Wenn das EEPROM programmiert 
wird steigt eigentlich die Stromaufnahme an. Wenn die Anbindung der 
Versorgungspannung nicht sauber ist kann es zu Störungen/fehlerhafter 
Programmierung kommen. Mögliche Ursachen: schlechte Masseanbindung 
(Potentialverschiebung), etc. Ich habe zwar diesbezüglich noch keine 
(negative) Erfahrung gemacht halte es aber für möglich.

Tschau

Christian

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, möglich ist das. Nur bei meinem Problem möchte ich das eigentlich 
ausschliessen. Die komplette Schaltung verbrät so ca. 60mA. So dass die 
geringe Stromerhöhung beim EEPROM-schreiben nicht ins Gewicht fällt.

Es wird ja auch beim normalen Betrieb nichts in den EEPROM geschrieben. 
Die Adresse wird nur ausgelesen.

MfG
Jörg

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch was (löst auch nicht wirklich das Problem, der Fehler tritt aber 
wesentlich seltener auf): nach dem Lesen das Adressregister auf einen 
anderen Wert setzen, also nicht auf einem benutzen Bytes stehen lassen. 
Und, speziell AVR, Byte0 gar nicht verwenden.

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so hab ich es beim pic gemacht. Nach jedem lesen/schreiben EEADR 
löschen. Hatte ich aber auch vergessen das ich das gemacht habe, erst 
als mikki mich darauf aufmerksam machte, sah ich nach und es war schon 
erledigt. Vieleicht hilft es bei dir <Jörg> auch, wenn Du es nicht schon 
längst hast.

Reiner

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp, EEADR bleibt natürlich auf dem ausgelesenen Wert 
stehen. Das werde ich auf jeden Fall auch mit ändern.

MfG
Jörg

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss ich beim Einsatz von externen seriellen EEPROMS (zB. 24LC256) mit 
ähnlichen Problemen rechnen oder kann ich die dort ausschließen?

Eine Checksumme für jeden Datensatz versteht sich von selbst. Damit kann 
ich zwar nicht die Daten wiederherstellen, erkenne aber ungültige 
Datensätze (welche es ja eigentlich nicht geben sollte). Für den 
Write-Protect Eingang hätte ich noch ein Pin frei. /WP werde ich über 
einen Pull-Up an Vcc legen (Wert muss ich mal in der Schaltung 
ausmessen, da der Wert des integrierten Pull-Down nicht im Datenblatt 
steht). Damit beim Einschalten auf jeden Fall das Schreiben des EEPROMs 
gesperrt ist. Durch den Mikrocontroller wird dann nur bei Bedarf das 
Schreiben freigegeben.

Fehler sollten dann, falls überhaupt, nur im Moment des Schreibens 
auftreten. Diese kann ich allerdings Problemlos durch ein nachfolgendes 
Prüflesen sofort erkennen und korrigieren. Na ja, mal vorrausgesetzt es 
kippt nicht aus irgendeinem Grund ein Bit um, selbst wenn Write-Protect 
gesetzt.

MfG
Jörg

Autor: BioSniper (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist eindeutig ein Hitzeproblem, Du Entwickler.

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt, wo sich der Staub, den du hier aufwirbelst, wieder gelegt hat, 
kann ich dich ja mal fragen, was dem angesprochenen Entwickler dein 
Statement nach 6 Jahren (!) noch nutzen soll?

/Hannes

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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