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
hi, wie sieht es aus mit abschirmung der kabel , erdung der gehaeuse bzw anlage.? abgeschirmte kabel beidseitig an erde..! ed
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
Hast du den deine Schaltung vorher hinreichend auf EMV und ESD getestet und entsprechende Prüfprotokolle?
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.
@ Reiner Tja, dann kann es ja wohl doch nur eine EMV-Problematik sein.?! oder doch nicht? MfG Jörg
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
War natürlich ein absoluter Schreibfehler "fehlende galvanische Kopplung" sollte natürlich "fehlende galvanische Trennung" heissen.
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
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
@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
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
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
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.