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
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
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
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
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
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.
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
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.
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
@ 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
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
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
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.
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
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
@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
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
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.
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
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
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
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.
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
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
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
