Ich habe für eine ortsansässige Firma einige "intelligente" Schrittmotortreiber konstruiert, eine weitere Firma baut diese und mein Kunde (ortsansässige Firma) programmiert die Dinger (meine Programme) mit maschinenspezifischen Parametern, ut diese in Geräte ein und verkauft diese. Die Dinger sind hundertfach überall in der Welt in Betrieb. Jetzt gibt es einen amerikanischen Kunden dessen Gerät vorab ausgetauscht wurde, das defekte ist nun hier. Es wurde bestätigt das das Teil "nur mal kurz ruckt", manchmal 2 bis 3 Zyklen geht und dann wieder nicht. Ich habe am Tel gesagt das die das Ding einfach mal neu mit dem selben Programm flashen sollen..Ergebnis: funktioniert. Das wirklich Interessante daran ist das das Austauschgerät in den USA angekommen ist und dort ab auspacken den selben Fehler hat (zu haben scheint). Derartige Ausfälle sind bisher völlig unbekannt. Der Prozessor ist ein Atmega16 mit 14,7456Mhz im TQFP Gehäuse, könnte gut sein das die aus der selben Serie stammen aber andere Geräte haben das Problem nicht. Programmiert wird mit einem Atmel ISP Adapter und AVRStudio4 (die Software mache ich anders). Das Netzteil ist eine Weitbereichswandwarze, die selbe für die USA und Europa.. Das Gerät besteht aus recht massiven Aluminium und Stahlteilen, so gut wie kein Plastik. Haltet Ihr es für möglich das die irgendwo beim Zoll das Ding so lange röntgen das der Flashinhalt "fadet"? Ist Jemandem anderen das schon mal passiert? Gruß, Holm
Holm T. schrieb: > Haltet Ihr es für möglich das die irgendwo beim Zoll das Ding so lange > röntgen das der Flashinhalt "fadet"? Ja das halte ich für möglich. Wir hatten vor etwa 10 Jahren Bekannten unsere Videokamera geliehen die mit nach Russland ging. Nach der Rückkehr (im Koffer, aufgegebenes Gepäck) ging die nicht mehr, Elektronik intern nicht mehr funktionsfähig. Diagnose lief auf gelöschten FLASH hinaus. Hat sich sicherlich Einiges geändert bis heute. Ich halte es nicht für ausgeschlossen, aber eher für eine unwahrscheinliche Fehlerursache. rgds
Als mein Smartphone am Flughafen durchleuchtet wurde (nachdem meine Klamotten (irttümlich) Bomben-Alarm auslösten), durfte ich die Speicherkarte vorher raus nehmen. Ich denke, das hatte schon seinen Grund. Da drängt sich natürlich die Frage auf, wer mir denn das Smartphone bezahlt hätte, wenn es nach der Untersuchung nicht mehr gestartet hätte.
>Da drängt sich natürlich die Frage auf, wer mir denn das Smartphone >bezahlt hätte, wenn es nach der Untersuchung nicht mehr gestartet hätte. Auf den Kosten bleibst du sitzen. Das Gleiche bei einer Hausdurchsuchung / Auto -> die Polizei räumt nicht wieder auf für dich. gruß J
Stefan U. schrieb: > Da drängt sich natürlich die Frage auf, wer mir denn das Smartphone > bezahlt hätte, wenn es nach der Untersuchung nicht mehr gestartet hätte. Du! Wer sonst & warum?
Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den bekommt man jedes Atmega-Flash kaputt.
Georg A. schrieb: > Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den > bekommt man jedes Atmega-Flash kaputt. Höre ich zum ersten Mal und glaube es dir einfach nicht.
Georg A. schrieb: > Falls der Brownout-Detektor nicht an ist, ist das ganz normal Und der erkennt die Röntgenstrahlen oder schirmt der die ab?
Georg A. schrieb: > Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den > bekommt man jedes Atmega-Flash kaputt. ??? bei ausgeschaltetem Gerät? ???? Wie das? Und selbst bei eingeschaltetem Gerät? Was hat der Brown-Out mit den Flash-Zellen zu tun?
Roger schrieb: > Georg A. schrieb: >> Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den >> bekommt man jedes Atmega-Flash kaputt. > > ??? bei ausgeschaltetem Gerät? ???? > Wie das? Zum Bleistift duch die Brownouts beim - langsam und vorsichtigen - Anstecken der Stromversorgung. Wenn der Flash wirklich durch Röntgenstrahlung komplett gelöscht wurde, müsste man eigentlich auch weitere Schäden im Chip wie einen erhöhten Stromverbrauch bemerken können.
Jim M. schrieb: > Wenn der Flash wirklich durch Röntgenstrahlung komplett gelöscht wurde, > müsste man eigentlich auch weitere Schäden im Chip wie einen erhöhten > Stromverbrauch bemerken können. Warum? Meinst Du wirklich, Silikon währe so anfällig auf Strahlung wie die Ladung in den Speicherzellen?
Stefan U. schrieb: > Als mein Smartphone am Flughafen durchleuchtet wurde (nachdem > meine Klamotten (irttümlich) Bomben-Alarm auslösten), durfte ich die > Speicherkarte vorher raus nehmen. Aha und den Flashspeicher des Smartphones auch? :-D
Peter D. schrieb: > Wird der SPM-Befehl benutzt? > Ist die BOR-Fuse enabled? Nein, im Programm gibt es nichts was den Flash programmieren sollte und Ja, 4V bei 5V Betrieb. Das würde aber auch nicht erklären wieso das 2 mal beim selben Überseekunden und sonst nie passiert.. Gruß, Holm
Jim M. schrieb: > Roger schrieb: >> Georg A. schrieb: >>> Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den >>> bekommt man jedes Atmega-Flash kaputt. >> >> ??? bei ausgeschaltetem Gerät? ???? >> Wie das? > > Zum Bleistift duch die Brownouts beim - langsam und vorsichtigen - > Anstecken der Stromversorgung. Das es heutzutage noch Leute gibt, die "Zum Bleistift" schreiben ist einfach rührend. Ansonsten verbreitest du den gleichen Unsinn wie Georg.
Holm T. schrieb: > Das würde aber auch nicht erklären wieso das 2 mal beim selben > Überseekunden und sonst nie passiert.. Überseecontainer Röntgen? http://www.weser-kurier.de/startseite_artikel,-Container-per-3DRoentgen-durchleuchten-_arid,699210.html
Holm T. schrieb: > Haltet Ihr es für möglich das die irgendwo beim Zoll das Ding so lange > röntgen das der Flashinhalt "fadet"? Mir ist das mal vor Jahren mit einem EPROM passiert, der ist auch gelöscht beim Kunden angekommen. D.h. er hat ihn zurück geschickt und es war alles 0xFF drin. Den 2. haben wir dann in Alufolie eingepackt, der ging dann.
Die Röntgenstrahlen senken wohl das Energieniveau, das nötig ist um die Elektronen tunneln zu lassen. So tunneln dann aus allen Ecken Elektronen -> überall 0xFF... Gruß J
fpga schrieb: > Die Röntgenstrahlen senken wohl das Energieniveau, das nötig ist um die > Elektronen tunneln zu lassen. So tunneln dann aus allen Ecken Elektronen > -> überall 0xFF... Das klappt bereits mit UV-Licht. Früher wurde dieser Effekt gezielt zum Löschen ausgenutzt, die ICs hatten dazu Glasfenster im Keramikgehäuse.
@PeDa: wenn das Röntgenstrahlung gewesen sein sollte, was soll die Alufolie daran verbessert haben? @fpga: ..Ja, der Effekt von ionisierender Strahlung auf Eproms und Flashroms (logischerweise auch RAM) ist mir bekannt, deswegen ja die Frage.. Cool ist natürlich auch diese Sentenz aus dem IEEE Link oben (danke!): "A second element was U.S. Postal Service (USPS) efforts to sterilize mail [1] and parcel shipments to a narrow selected range of zip codes as an anthrax antidote. USPS dose values are extremely high (5–10 Mrads using a 10-MeV electron beam using hundreds of kilowatts!) such that neither commercial devices (see Table I, taken from [2]–[7]) nor even “Rad Hard” devices (not shown) would survive." Betreffs Brownout: Warum zur Hölle läßt sich das eigentlich in den Atmegas überhaupt disablen, wozu ist die Fuse gut? Die beiden unterschiedlichen Pegel begreife ich ja noch, aber wann stört ein Reset und es ist vorzuziehen mit kaputten Daten weiter zu rechnen? Ich schalte den Kram immer ein. Früher(Tm) gabs diese Fuse in Hardware, 7705 vorhanden oder nicht.. Gruß, Holm
> Als mein Smartphone am Flughafen durchleuchtet wurde ..., > durfte ich die Speicherkarte vorher raus nehmen. Aha und den Flashspeicher des Smartphones auch? :-D Leider nicht. Ich speichene meine Medien aber weitestgehend auf der SD Karte, insofern machte ich mir nur Sorgen, dass das Gerät nachher nicht mehr booten kann.
>@PeDa: wenn das Röntgenstrahlung gewesen sein sollte, was soll die >Alufolie daran verbessert haben? Also Titan sieht man gut aufm Röntgenbild ;) da geht keine Strahlung durch. Wie das mit Alu ist, keine Ahnung. Mylar könnte da helfen?! Gruß J
Horst schrieb: > Silikon währe so anfällig auf Strahlung Meintest du Silizium? Dem Klaus Lage als dembezüglichen Laien kann man das ja noch nachsehen, aber hier im Elektroniker-Forum sollte das nicht passieren...
Lothar M. schrieb: > Horst schrieb: >> Silikon währe so anfällig auf Strahlung > Meintest du Silizium? Natürlich, das passiert, wenn man den ganzen Tag auf englisch diskutiert. Aber das weiche Zeug ist auch nicht anfällig.
Also hier mal ein Text des Speicherherstellers Kingston zum Thema: 6. Avoid U.S. Postal Service radiation scanning of mailed packages. According to the CompactFlash Association, X-ray scanners at airports will not damage CompactFlash cards but radiation scanning by the U.S. Postal Service may damage them. 1 Because of this warning by the CompactFlash Association regarding mail irradiation by the U.S. Postal Service, it may be preferable to use a commercial service such as FedEx, UPS or other private carrier as an alternative to mailing Flash storage devices by U.S. mail.
Moin, ich habe dafür keine 100%igen Beweise, aber meine Bilanz ist bisher: - defekte Kamera (Steuerchip hinüber) - Permanente Flashdefekte auf einem Billig-USB-Stick - Gekippte Sektoren auf nem NAND-Chip - Pixeldefekte auf optischem Sensor - Pixeldefekt auf Handykamera Die Pixeldefekte liessen sich alle unmittelbar nach Flugreisen feststellen, aber nicht direkt aufs Röntgen zurückführen, denn auch in einer Kabine kann mal ein schnelles Elementarteilchen vermehrt wo reinknallen. Aber: bei Flash dürfte die Energie ausreichen, eine schlecht abgeschirmte Flash-Zelle genügend zu ionisieren, dass ein Bit kippt. Mir hat mal ein Insider gesagt, dass es besser sei, Datenträger nicht im aufgegebenen Gepäck zu lassen, da mancherorten einfach mal die Leistung hochgedreht wird, wenn nicht genug gesehen wird. Beim Handgepäck seien die Bedingungen anders und die Geräte teils moderner. Es wird immer wieder beteuert, dass die Energie extrem niedrig sei und man Schäden ausschliessen könne, aber die Physik kann man halt nicht austricksen. Auf jeden Fall ist es eine gute Idee, ne SSD in eine Blechbox zu packen.
Strubi schrieb: > Mir hat mal ein Insider gesagt, dass es besser sei, Datenträger nicht im > aufgegebenen Gepäck zu lassen, da mancherorten einfach mal die Leistung > hochgedreht wird, wenn nicht genug gesehen wird. upps http://www.spiegel.de/reise/aktuell/handgepaeck-auf-usa-fluegen-warum-laptops-nun-verboten-sind-a-1139907.html
Holm T. schrieb: > Ist Jemandem anderen das schon mal passiert? Ja, hat schon einen Grund, weshalb ich gewisse Steuerungen immer noch mit Widerstands-Transistor-Logik diskret aufbaue. Für andere Zwecke habe ich schonmal EPROMS durch batteriegepufferte SRAMs ersetzt. Echte Rad-Hard-Bauteile waren mir zu teuer... Probleme mit "Speicherverlust beim Versand" hatte ich aber bislang noch nicht. Es hilft übrigens, die EPROMs und EEPROMs mit der maximal zulässigen (Betriebs-)Spannung zu programmieren.
Holm T. schrieb: > Betreffs Brownout: Warum zur Hölle läßt sich das eigentlich in den > Atmegas überhaupt disablen Weil das Ding zusätzlich Strom braucht.
Strubi schrieb: > Mir hat mal ein Insider gesagt, dass es besser sei, Datenträger nicht im > aufgegebenen Gepäck zu lassen, da mancherorten einfach mal die Leistung > hochgedreht wird, wenn nicht genug gesehen wird. Beim Handgepäck seien > die Bedingungen anders und die Geräte teils moderner. Beim Handgepäck steht einer direkt neben dem Scanner und die Gepäckzuführungen sind nur mit Gummilappen geschützt. Das setzt gewisse Grenzen (Energie, Dosisleistung), weil man Grenzwerte einhalten muss. Bei Röntgengeräten für aufgegebenes Gepäck kann man dagegen einfach einen Strahlenschutzbereich einrichten.
Schreiber schrieb: > und die Gepäckzuführungen sind nur mit Gummilappen geschützt. Informier Dich doch mal, warum diese Gummilappen deutlich schwerer sind als normales Gummi.
Horst schrieb: > Aber das weiche Zeug ist auch nicht anfällig. Insbesondere Silikonkleber sind für manche Anwendungen nicht ratsam, eher epoxy. http://cds.cern.ch/record/531818/files/CERN-2001-006.pdf?version=1 Das hängt natürlich von Energie und Dosis ab.
Horst schrieb: > Informier Dich doch mal, warum diese Gummilappen deutlich schwerer sind > als normales Gummi. Auch schweres Gummi mit Bleistaub drin, hat nur eine begrenzte Abschirmwirkung, zumal so ein Lamellenvorhang nicht 100% dicht ist.
Jörg W. schrieb: > Holm T. schrieb: >> Betreffs Brownout: Warum zur Hölle läßt sich das eigentlich in den >> Atmegas überhaupt disablen > > Weil das Ding zusätzlich Strom braucht. Lieber Jörg, zitiere mal bitte weiter.. Wozu soll das gut sein sparsam Mist zu rechnen? Gruß, Holm
Schreiber schrieb: > Strubi schrieb: >> Mir hat mal ein Insider gesagt, dass es besser sei, Datenträger nicht im >> aufgegebenen Gepäck zu lassen, da mancherorten einfach mal die Leistung >> hochgedreht wird, wenn nicht genug gesehen wird. Beim Handgepäck seien >> die Bedingungen anders und die Geräte teils moderner. > > Beim Handgepäck steht einer direkt neben dem Scanner und die > Gepäckzuführungen sind nur mit Gummilappen geschützt. Das setzt gewisse > Grenzen (Energie, Dosisleistung), weil man Grenzwerte einhalten muss. > > Bei Röntgengeräten für aufgegebenes Gepäck kann man dagegen einfach > einen Strahlenschutzbereich einrichten. Das ist aber nur Deine Idee das es sich um profane Gummilappen handelt? Warum ist dann dort nicht ne hybsche Gardine dran? Gruß, Holm
Hi, Wir hatten bei uns auch mal so einen Verdacht, und haben das daraufhin mal getestet. Dazu haben wir unsere Platine in einem industriellen Röntgentomographen unter Beschuss genommen. Allerdings hat sich der PIC16F72 dadurch nicht stören lassen. Nicht mal Einzelbitfehler sind aufgetreten. Physikalisch ist es auf jeden Fall möglich eine Flash-Zelle durch ionisierende Strahlung zu beeinflussen. Wie leicht das geht hängt sicher von vielen Faktoren ab. Ich kann mir vorstellen, dass die hochintegrierten SD und SSD Speicher deutlich anfälliger sind, als ein Mikrocontroller, der ja nur ein paar kByte halten muss. Für Deine gelöschten AVRs kommen aber auch andere Effekte in Frage: - Flash kann man auch durch EMI löschen. Oben wurde bereits der Brown-Out angesprochen. Selbst gesehen habe ich schon dass Flash-Bausteine durch einen Burst-Impuls gelöscht wurden. - Es gibt auch schlechte Controller-Chargen. Wir haben aktuell eine Reklamation gestartet, bei der die betroffenen Mikrocontroller im Laufe der Zeit Bit-Kipper aufweisen. Bis hin zum komplett leeren Flash. Einmal Neuprogrammieren, und der µC funktioniert wieder. Ist aber kein Controller von Atmel.
:
Bearbeitet durch User
Holm T. schrieb: > Wozu soll das gut sein sparsam Mist zu rechnen? Du solltest dich dringend mit der Mikrocontrollerentwicklung vertraut machen.
Es gibt auch noch die Möglichkeit, dass ein alpha-Strahler im Spiel ist. Kein Witz. Anscheinend haben einige Hersteller zunehmend das Problem, dass der Gehäusekunststoff durch radiaktives Material kontaminiert ist, und es so durch radiaktiven Zerfall zu Einzelbitfehlern kommt. Alpha-Teilchen lassen sich normalerweise sehr leicht abschirmen, aber eben nicht, wenn das Package selbst strahlt.
Holm T. schrieb: > Ich habe am Tel gesagt das die das Ding einfach mal neu mit dem selben > Programm flashen sollen..Ergebnis: funktioniert. Gut zu wissen. Bekommt der Kunde halt die Soft per email, dann geht sie nicht verloren. LG old.
Ist übrigens durchaus hilfreich, wenn die Software sich beim Hochlaufen selber mal auf CRC prüft und ggf. irgendeine Art von Fehleranzeige ausgibt. Noch fieser als "geht gar nicht" ist nämlich "geht meistens, aber gelegentlich instabil oder falsch". Dann kann der Kunde sogar selber den Defekt diagnostizieren.
Bei mir ist es schon einmal passiert - bei einen kleinen Microchip PIC hat sich der Flashspeicher durch EMV verändert - also an Kunden ausgelieferte Baugruppen immer so ausliefern, das nichts mehr progammiert werden kann. Die Produkte sind doch fertig entwickelt?
Hatte der Atmega16 denn noch eine gültige Signatur? Diese ist normalerweise ja durch keinen Befehl beschreibbar, aber offensichtlich selbst eigentlich auch nur im Flash abgelegt. Jedenfalls habe ich hier einen Atmega8, der nach kurzer Zeit stehts seinen Flash verliert - und dieser hat seit dem Defekt auch eine falsche Signatur.
Malte _. schrieb: > Diese ist normalerweise ja durch keinen Befehl beschreibbar, aber > offensichtlich selbst eigentlich auch nur im Flash abgelegt. Ja, ist sie. Lediglich die JTAG-ID ist tatsächlich in Hardware gegossen. Der Rest sind Fuses, also Flash.
Baldrian schrieb: > Georg A. schrieb: >> Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den >> bekommt man jedes Atmega-Flash kaputt. > > Höre ich zum ersten Mal und glaube es dir einfach nicht. Nur zu, mach ruhig deine eigenen Erfahrungen. Ich dachte auch nicht, dass der BOR wichtig ist. Aber wenn das Ding dann mal in die 1000er Stückzahlen kommt, wird es statistisch schon auffällig... Ich konnte es dann recht gut mit mit Wackeln der Bananenstecker im Labornetzteil reproduzieren. Heisst nicht, dass das nicht auch mit Röntgen passieren kann, aber erstmal sollte man die anderen möglichen Probleme ausschliessen...
> > Nur zu, mach ruhig deine eigenen Erfahrungen. Ich dachte auch nicht, > dass der BOR wichtig ist. Aber wenn das Ding dann mal in die 1000er > Stückzahlen kommt, wird es statistisch schon auffällig... Ich konnte es > dann recht gut mit mit Wackeln der Bananenstecker im Labornetzteil > reproduzieren. > > Heisst nicht, dass das nicht auch mit Röntgen passieren kann, aber > erstmal sollte man die anderen möglichen Probleme ausschliessen... Die Brownout-Thematik würde ich so mit unterschreiben (allerdings für eine andere CPU-Architektur). In eine ähnliche Richtung gehen ja auch die Ansätze zum Glitching, um zur richtigen Zeit ein Bit zum Kippen zu bringen oder gar Fuses nutzlos zu machen. Bei vernünftiger Spannungsüberwachung wird das deutlich schwieriger. Es gibt noch einen anderen Aspekt, der in Bezug auf die defekten optischen Sensoren für Kopfschmerzen gesorgt hat: Reine Röntgenstrahlung als solche sollte eigentlich dem Pixel nicht schaden. Aber wenn durch die Ionisation an benachbarten Layerelementen Ladung aufgebaut wird und zusätzlich noch Felder von den Transportbändern (reibende Gummibänder als "Van der Graaf-Generator") dazukommen, könnte eine statische Entladung auch mechanischen Schaden an der Chipoberfläche anrichten. Bisher habe ich noch keine plausible Antwort auf die Todesursache der Handy-Pixel (in diesem Fall schwarz) gefunden.
Georg A. schrieb: > Ich konnte es > dann recht gut mit mit Wackeln der Bananenstecker im Labornetzteil > reproduzieren. Ja das ist Mist bei den Dingern. Betrifft das nur die AVR oder kann man auch PIC, STM u.a. "totwackeln"?
Baldrian schrieb: > Georg A. schrieb: >> Falls der Brownout-Detektor nicht an ist, ist das ganz normal. Ohne den >> bekommt man jedes Atmega-Flash kaputt. > > Höre ich zum ersten Mal und glaube es dir einfach nicht. Hmmhmm. Ich kenne das von den ATMEL SAM7. Hat jetzt nichts mit dem ATMEGA zu tun, aber die haben sich diverse Flashinhalte selber gelöscht, extrem sporadisch. Nach aktivieren den Brown-Out war das Problem weg. War ein Softwarefehler, eigentlich hätte der Brown out aktiv sein müssen. Nicht zum Spass gibts eine nette Kollektion Resetbausteinen von diversen Herstellern. Spätestens wenn der Kram in irgeneinem Entwicklungsland mit wackeliger Stromversorgung steht, hat es sich schnell "ausgespart" ;-) Weil das Stromsparagument kam: http://www.microchip.com/wwwproducts/en/MCP102 2µA wird man doch wohl übrig haben. Es geht auch noch beträchtlich weniger, wenn es sein muss.
batman schrieb: > Georg A. schrieb: >> Ich konnte es >> dann recht gut mit mit Wackeln der Bananenstecker im Labornetzteil >> reproduzieren. > > Ja das ist Mist bei den Dingern. Betrifft das nur die AVR oder kann man > auch PIC, STM u.a. "totwackeln"? AVRs "totwackeln" - der Unfug in diesem Forum treibt kuriose Blüten.
Kann man euch originellen Typen irgendwo beim Totwackeln von AVR-Controller live sehen? Würde gerne vorbeikommen und mir dies anschauen. Ort & Termin bitte bekanntgeben.
Kommst du auch noch dahinter. Hurra schrieb: > 2µA wird man doch wohl übrig haben. Es geht auch noch beträchtlich > weniger, wenn es sein muss. Wir sind bei AVR, da sind es schon 10µA für den BOD und spätestens damit inakzeptabel für Knoppzellenbetrieb.
Alex W. schrieb: > Konkurrenzfirma? Genau, das muß die PIC-Fraktion sein. Die wollen Atmel schon lange schlecht machen und aufkaufen ... ups ;-p
Hurra schrieb: > Spätestens wenn der Kram in irgeneinem Entwicklungsland mit wackeliger > Stromversorgung steht, hat es sich schnell "ausgespart" ;-) ...großzügig ausgelegte Netzteil-Elkos und eine saubere Power-Down-Routine helfen. Für kritische Baugruppen sollte man die Stromversorgung in Entwicklungsländern auf auf 2-5 Sekunden(!) Netzunterbrechung auslegen. Kostet zwar, hilft aber Problemen vorzubeugen. Das Netzteil sollte man ebenfalls "etwas" robuster in Bezug auf Über- und Unterspannung auslegen. In ganz hartnäckigen Fällen verwendet man eine USV, entweder intern (meist einfacher und wirtschaftlicher) im Gerät eingebaut oder extern. Sollte man dem Kunden aber nicht auf die Nase binden, der reagiert meist beleidigt, wenn man ihm sagt, dass er mit der "Shithole-Version" beliefert wurde...
batman schrieb: > Nützt alles nix bei einem Gerät mit Batteriefach. Auch da kann die Stromversorgung Morsezeichen geben, wenn man das Gerät schüttelt. Also auch puffern, wenngleich es gerne vergessen wird. Alternativ die Batterie fest einlöten...
Schreiber schrieb: > In ganz hartnäckigen Fällen verwendet man eine USV, entweder intern > (meist einfacher und wirtschaftlicher) im Gerät eingebaut oder extern. > Sollte man dem Kunden aber nicht auf die Nase binden, der reagiert meist > beleidigt, wenn man ihm sagt, dass er mit der "Shithole-Version" > beliefert wurde.. Ich sag dann immer: Was hamse denn, so heisst der Flughafen nahe Amsterdam...
Kh L. schrieb: > Es gibt auch noch die Möglichkeit, dass ein alpha-Strahler im Spiel ist. > Kein Witz. Anscheinend haben einige Hersteller zunehmend das Problem, > dass der Gehäusekunststoff durch radiaktives Material kontaminiert ist, Heute wieder? Das war ein Problem vor zig Jahren und plagte massgeblich DRAM-Chips. Wär das seither nicht besser wesentlich geworden, dann würden heutige Normal-PCs nur mit massivem ECC-Einsatz länger durchhalten.
Baldrian schrieb: > Holm T. schrieb: > >> Wozu soll das gut sein sparsam Mist zu rechnen? > > Du solltest dich dringend mit der Mikrocontrollerentwicklung vertraut > machen. Du beliebst zu scherzen... Gruß, Holm
Nop schrieb: > Ist übrigens durchaus hilfreich, wenn die Software sich beim Hochlaufen > selber mal auf CRC prüft und ggf. irgendeine Art von Fehleranzeige > ausgibt. Noch fieser als "geht gar nicht" ist nämlich "geht meistens, > aber gelegentlich instabil oder falsch". > > Dann kann der Kunde sogar selber den Defekt diagnostizieren. Da ist simpel nichts zum "Fehleranzeigen" dran. Gruß, Holm
Alex W. schrieb: > Für mich klingt das langsam nach avr-flame! > > Konkurrenzfirma? ..Lötzinn. Ich habe kein Problem z.B. einen MSP430 da drauf zu setzen oder aus Preisgründen auch einen STM32. Der Atmega16 ist ja auch nicht gerade das neueste Produkt.... Stromsparen ist völlig uninteressant in diesem Fall weil sich der Stepper nicht aus einer Knopfzelle betreiben läßt. Mich interessiert nur wie der Ami-Kunde das macht... kein Anderer hatte bisher derartige Probleme. Gruß, Holm
A. K. schrieb: >> dass der Gehäusekunststoff durch radiaktives Material kontaminiert ist, > > Heute wieder? Das war ein Problem vor zig Jahren und plagte massgeblich > DRAM-Chips. Ich kenne das auch nur von keramischen Gehäusen, und nur bei dRAMs. Abhilfe war das Beilegen eine 50 µm starken Polyesterfolie, die genügt, um Alphateilchen vollständig abzuschirmen. Holm T. schrieb: > Stromsparen ist völlig uninteressant in diesem Fall Schon klar, aber du hattest ja gefragt, warum man den BOD überhaupt abschaltbar gemacht hat.
batman schrieb: > Wir sind bei AVR, da sind es schon 10µA für den BOD und spätestens damit > inakzeptabel für Knoppzellenbetrieb. Damit disqualifiziert sich der AVR doch eigentlich völlig für den Knopfzellenbetrieb. Mir ist es zweimal mit einem Prototypen passiert, dass er sein Programm vergessen hat. Versorgt wurde er mit einer 9V Blockbatterie über einen 7805. Dummerweise hatte ich vergessen die Batterie nach dem Test abzuklemmen, sodass sie am nächsten Morgen leer war. Dabei hat der AVR (ATmega 8) allerdings auch sein Programm vergessen. Wenn ich mir nun vorstelle, dass ich mir bei einer Knopfzelle den Brown Out aus Stromspargründen nicht leisten könnte, dann wäre das doch am Sinn vorbei?
fpga schrieb: > Auf den Kosten bleibst du sitzen. Das Gleiche bei einer Hausdurchsuchung > / Auto -> die Polizei räumt nicht wieder auf für dich. Das stimmt so nicht. Bei frühren Nachbarn wurde die Wohnung mal wohl Aufgrund einer Verwechselung verwüstet. Die Leute mußten allerdings Klagen und haben irgendwann auch Recht und Kohle bekommen.
Flash nach röntgen korrupt, dafür reicht die Energie der Strahlung nicht. Gefährlicher ist da - aufgrund der Höhe - der Flug. Bei Flughardware wird mit single event upsets im Flash gerechnet. Wer dazu Details sucht, hier: https://nepp.nasa.gov/docuploads/31342D2C-05DD-4165-88EC472A3AB88B6A/SEU_Flash-97.pdf Container auf Meereshöhe ist also besser ;-) Bei Serienhardware funktionieren die schnellen Garagen-Lösungen nur fast immer (Statistik). Außerhalb der Garage verwenden Entwickler gerne Reset-Bausteinen #1. Wenn es um jeden Cent geht (Consumer oder Automotive), und Dir die Einkäufer im Nacken sitzen: #2 (hier wird auch gut erklärt, warum die Brown-Out-Erkennung nur bedingt hilft). #1 http://www.ti.com/lsds/ti_de/power-management/supervisor-reset-ic-products.page# #2 http://www.st.com/content/ccc/resource/technical/document/application_note/7b/73/6a/eb/55/15/48/26/CD00003839.pdf/files/CD00003839.pdf/jcr:content/translations/en.CD00003839.pdf
Danke für die Links. Ein paar Fragen habe ich dazu: BUZ schrieb: > Reset-Bausteinen #1 open Drain, wie soll der den Reset bei Unterspannung halten? Es ist doch zu wenig Spannung da um den FET leitend zu halten. BUZ schrieb: > #2 Fig. 1 und 2 10µF Fig. 3 Für den arduino nano braucht es etwa 20mA um den Resetpin an GND zu legen. Das kann ein 10K Widerstand nicht. Auch der HIGH Pegel wird nicht erreicht, weil der Betrag von UDz plus Ube kleiner als 5V ist. Doch besser selbstbasteln? LG old.
Jörg W. schrieb: [..] > > Holm T. schrieb: >> Stromsparen ist völlig uninteressant in diesem Fall > > Schon klar, aber du hattest ja gefragt, warum man den BOD überhaupt > abschaltbar gemacht hat. Jörg wenn wir davon ausgehen das bei Batteriebetrieb der BODLEVEL bei minimal 2,5V liegt und darunter, wie hier suggeriert wird, kein zuverlässiger Betrieb und auch keine Sicherheit für den Flash-Inhalt gegeben ist, warum sollte es dann notwendig erscheinen die Brownoutfuse nicht zu aktivieren? Sie verhindert gewissermaßen die Zerstörung des Devices im Feld oder aber auch das Weiterrechnen mit korrupten Daten. Wozu also benötige ich eine stromsparende EDV deren Ergebnissen ich nicht mehr trauen kann oder die sich bei leerer Batterie selbst zerstört? Gruß, Holm
Ich bastle seit fast 10 Jahren mit AVR und hatte noch nie Verlust im Flash zu beklagen. Den brown-Out Detektor habe ich noch nie benutzt, außer ein einziges mal: In Kombination mit einem CP2201 Ethernet Controller habe ich den BOD verwendet, weil ich im EEPROM des Ethernet Controllers wiederholt Daten verloren hatte. Der AVR war nicht das Problem! Ich habe zuhause mehrere elektronische Spiele herum liegen, die seit Jahren mit CR2032 Knopfzellen betrieben werden. Bisher hat keines davon jemals eine Fehlfunktion gehabt. BOD ist ganz sicher optional.
Ich hatte die BOD auch eher beim (internen) EEPROM auf dem Schirm - da hab ich mir ohne auch schon den Inhalt zerschossen.
batman schrieb: > Wir sind bei AVR, da sind es schon 10µA für den BOD und spätestens damit > inakzeptabel für Knoppzellenbetrieb. Das ganze ist sogar noch viel schlimmer. Sinkt die VCC unter den BOD-Level, wird das interne Reset aktiviert, d.h. der MC verläßt den Sleep-Mode, schaltet den Oszillator an und verbraucht wieder soviel Strom, wie im active-Mode. Somit wird ein Akku tiefentladen, also zerstört. Man darf also bei Akkubetrieb das BOR nicht enablen. Vermutlich ist dieser Designfehler aber nicht nur in den AVRs. Ich hab zu Hause schon einige Geräte, wo ich die Akkus rausnehmen muß, wenn ich sie ne Weile nicht benutzen will, sonst sind die Akkus tot. Ich hab das mal nachgemessen. Die Akkuspannung sank stetig von Tag zu Tag und das Gerät ging auch immer in Sleep. Und plötzlich waren die Akkus am nächsten Tag tiefentladen. Ein durchdachtes Design würde den Oszillator erst anschalten, wenn die VCC den BOD-Level wieder überschreitet, bzw. bei Unterschreiten des BOD-Level Sleep erzwingen, d.h. den Oszillator stoppen.
Holm T. schrieb: > Jörg W. schrieb: > [..] >> >> Holm T. schrieb: >>> Stromsparen ist völlig uninteressant in diesem Fall >> >> Schon klar, aber du hattest ja gefragt, warum man den BOD überhaupt >> abschaltbar gemacht hat. > > Jörg wenn wir davon ausgehen das bei Batteriebetrieb der BODLEVEL bei > minimal 2,5V liegt und darunter, wie hier suggeriert wird, kein > zuverlässiger Betrieb und auch keine Sicherheit für den Flash-Inhalt > gegeben ist, warum sollte es dann notwendig erscheinen die Brownoutfuse > nicht zu aktivieren? Sie verhindert gewissermaßen die Zerstörung des > Devices im Feld > oder aber auch das Weiterrechnen mit korrupten Daten. > Wozu also benötige ich eine stromsparende EDV deren Ergebnissen ich > nicht mehr trauen kann oder die sich bei leerer Batterie selbst > zerstört? > > Gruß, > > Holm Das Design der Anwendung (also der Entwickler) muß sicherstellen, daß sein Gerät korrekt funktioniert. Zur Startup/Reset/Shutdownlogik gibt es zahlreiche hard- und softwaremäßige Techniken, um das zu gewährleisten. Die MC können nicht für jede Anwendung optimal ausgeliefert werden. Bei meinem alten PDA wird z.B. der Strom über die Batterieklappenverriegelung beim Wechsel aus- und eingeschaltet. Es gibt sicher noch lustigere Beispiele. Eine ext. RESET-Logik war mal Standard und bei Armbanduhren mußte man manchmal alle vier Tasten drücken, damit sie korrekt anlaufen.
batman schrieb: > Zur Startup/Reset/Shutdownlogik gibt es > zahlreiche hard Beitrag "Unterspannungsreset" LG old.
Jetzthabensieihn I. schrieb: > open Drain, wie soll der den Reset bei Unterspannung > halten? Es ist doch zu wenig Spannung da um den FET > leitend zu halten. Der uralte Texas TL770x hat unterhalb einer gewissen Versorgung einen undefinierten Ausgang - schaue Dir mal Seite 13 / Figure 15 an. Ich denke, dass ist sinngemäß auch auf andere Bausteine anwendbar.
Er muß ja auch erst vor Erreichen einer gültigen Vcc einen definierten Pegel liefern - also Resetten.
Stefan U. schrieb: > Ich bastle Genau. Das ist das Poblem. Solche Probleme treten gerne sporadisch auf. Bei meinem SAM7-Problem hatten wir einen Testaufbau mit 100 Platinen laufen, und der Fehler trat etwas 1 mal pro Wochenende auf. Bei zehntausenden Schaltvorgängen. Die hat man schnell zusammen, bei 50k Boards im Feld. Bei deinem 1-Stück-Bastelkram in 10 Lebensaltern nicht. Drum kannst du auch weiter gerne ohne Brown-Out arbeiten. Für einen Entwickler mit 10k Platinen bei "kreativen" Kunden mit "interessanter" Stromversorgung ist das lediglich eine komplizierte Form von Seppuku. --> Verallgemeinerung sucks.
Jetzthabensieihn I. schrieb: > Für den arduino nano braucht es etwa 20mA um den > Resetpin an GND zu legen. Manfred schrieb: > schaue Dir mal Seite 13 / Figure 15 an. Was sind denn das für Lösungsvorschläge. :-( Zum Einen reicht 1K nicht als Polldown und zum Zweiten hängt der im Betrieb ständig als Lastwiderstand in der Schaltung. LG old.
Nop schrieb: > Holm T. schrieb: > >> Da ist simpel nichts zum "Fehleranzeigen" dran. > > Wie, nichtmal eine Leuchtdiode? Hat Dein Wasserhahn am Waschbecken Leuchtdioden? Wozu sollte ich auf ein Einzelteil unsichtbar im Inneren einer Maschine LEDs platzieren? :-) Es gibt sogar 2 auf der Platine, eine für die Nullstellung im TB6560 und eine für den Protect Status. Beide Signale gehen "durch den AVR" und währen ggf. in dieser Richtung steuerbar. Problem:Ich habe keinen Auftrag für ein Mäusekino und das ist bisher der einzige bekannte Fall. Gruß, Holm
Also dann nur ein kurzer Heißwasserschwall bei Checksummenfehler. :)
batman schrieb: > Also dann nur ein kurzer Heißwasserschwall bei Checksummenfehler. :) Und das verhindert einen fehlerhaften Flashinhalt?
Nein, es ging nur um die Fehlermeldung. Bei einem Defekt in der Steuerung besteht i.d.R. Handlungsbedarf. Beliebt ist ja auch das Beeeeeeeeeeeeeeep Beeeeeeeeeeeeeeep beim PC.
batman schrieb: > Nein, es ging nur um die Fehlermeldung. Bei einem Defekt in der > Steuerung besteht i.d.R. Handlungsbedarf. Beliebt ist ja auch das > Beeeeeeeeeeeeeeep Beeeeeeeeeeeeeeep beim PC. ..das ist nur für einfach strukturierte Leute, der Rest bekommt mit das das Ding einfach nicht tut.. Gruß, Holm
Holm T. schrieb: > ..das ist nur für einfach strukturierte Leute, der Rest bekommt mit das > das Ding einfach nicht tut.. Hat halt zum Troubleshooting Vorteile, wenn das Gerät einen Fingerzeig geben kann, wieso es nicht mehr will. Der Techniker an der Hotline bekommt damit schneller eine Lösung. Viele Geräte haben eben deswegen einen Selbsttest beim Hochfahren. Wenn aber nicht "sowieso" schon LEDs, externe Kommunikationsschnittstellen oder sonstwas gefordert sind, ist es andererseits natürlich auch eine Abwägung, ob man eigens dafür nun wirklich eine Status-LED verbauen will mitsamt dem Zusatzaufwand in der Gehäusefertigung und womöglich Wasser/Staubfestigkeit. Im Normalfall braucht der Kunde es ja nicht und will daher halt auch oft dafür nicht bezahlen.
Jetzthabensieihn I. schrieb: > Danke für die Links. > Ein paar Fragen habe ich dazu: > > BUZ schrieb: >> Reset-Bausteinen #1 > > open Drain, wie soll der den Reset bei Unterspannung > halten? Es ist doch zu wenig Spannung da um den FET > leitend zu halten. > > BUZ schrieb: >> #2 > > Fig. 1 und 2 10µF > Fig. 3 > Für den arduino nano braucht es etwa 20mA um den > Resetpin an GND zu legen. Das kann ein 10K Widerstand > nicht. > Auch der HIGH Pegel wird nicht erreicht, weil der > Betrag von UDz plus Ube kleiner als 5V ist. > > Doch besser selbstbasteln? > > LG > old. #1 Muss er ja nicht, die Aufgabe ist nach erreichen einer stabilen (guten) Versorgungsspannung einen hinreichend langen Reset sicherzustellen ODER bei kurzen Einbrüchen (prellen) der Versorgungsspannung. Bei Unterspannung sorgt die BOD dafür, dass der uC kein "Blödsinn" macht. #2 Generell gilt, das Bauteil muss zu den (deinen) Anforderungen passen. Ich kann mir jedoch nicht vorstellen, dass es keinen cots (commercial off-the-shelf) Reset-Baustein für dein Problem gibt. "selberbasteln" sollte man nur wenn a.) jeder Cent zählt (Stückzahl sehr hoch) oder b.) die Verfügbarkeit über einen langen Zeitraum (>10 Jahre) sichergestellt werden muss (Mil-Projekte) oder c.) es keine cots Lösung zu den gegebene Anforderungen (Temperatur, Spannung, Strom, usw.) gibt. 20mA um den Reset Pin auf GND zu legen - da stimmt bei Deiner Schaltung was nicht. Gemäß dem SLP vom Nano #3 hängt da nichts dran (außer der interne PullUp). Wo soll der Strom herkommen - aus dem Pin oder dem gesteckten Programmieradapter? #3 https://www.dfrobot.com/wiki/images/3/31/Arduino_Nano_Schematic.png
Jetzthabensieihn I. schrieb: > Zum Einen reicht Zur allgemeinen Information: Beim Arduino gibt es (u.A.!) einen Pullup Widerstand am Reset. Dieser beträgt beim UNO 10K und beim NANO 1K. Damit muss ein Unterspannungsreset Schaltkreis erstmal klar kommen. BUZ schrieb: > 20mA Habe ich falsch gerechnet, es sind 5mA. Es braucht < 220 Ohm nach GND für einen sicheren Reset. BUZ schrieb: > sorgt die BOD Angeblich passt die Schwelle nicht zur XTAL-Frequenz: http://jasper.sikken.nl/arduinobootloader/index.html LG old.
> Jetzthabensieihn I. schrieb: > Zur allgemeinen Information: > Beim Arduino gibt es (u.A.!) einen Pullup Widerstand > am Reset. > Dieser beträgt beim UNO 10K und beim NANO 1K. > Damit muss ein Unterspannungsreset Schaltkreis > erstmal klar kommen. > Habe ich falsch gerechnet, es sind 5mA. Es braucht < 220 Ohm > nach GND für einen sicheren Reset. Ja, falsch gerechnet, aber ich habe auch die 1k übersehen. Für sicher low muss der Reset, gemäß uC Datenblatt, kleiner 0,1xVCC sein. Mit 1k PullUp folgt somit < 111 Ohm! Eher noch kleiner, weil der Pin intern bereits ein PullUp hat. Strom stimmt, mit diesen ~5mA kommen (fast) alle Reset-Bausteine klar, die meisten können 10mA oder 20mA gegen GND.
BUZ schrieb: > diesen ~5mA kommen (fast) alle > Reset-Bausteine klar, die meisten können 10mA oder 20mA gegen GND. Beim Hochfahren der Betriebsspannung muss der Resetbaustein dann aber spätestens deutlich unterhalb von Vin = 2,7V den ResetPin LOW halten. Wenn Du da ein Reset-IC, am liebsten TO92 im Ärmel hast, bitte raus damit. BUZ schrieb: > Für sicher > low muss der Reset, gemäß uC Datenblatt, kleiner 0,1xVCC sein. Aha, meine Experimente haben ergeben, dass es genügt < 1V für einen sicheren Reset zu haben. Habe meine Zwei-Transistorschaltung darauf augelegt. BUZ schrieb: > übersehen Kein Wunder. In dem Schaltbild erkennt man nicht mit welchen Punkten der ResetPin verbunden ist. Da kommt man eher zufällig drauf. Übrigens hängt da noch ein 100nF zum DTR des USB-IC dran. Ob dem DTR_Pin das Drücken des Resettasters weh tut? Zu der Sache XTAL-Frequenz und BOD ( in meiner Welt uvlo für under voltage log out) Ich kann mir vorstellen, dass da für einen sicheren Betrieb bei der niedrigsten Umgenungstemperatur garantiert werden soll. Deshalb klappt das mit 16MHz bei Raumtemperatur auch. Was meinst Du dazu? LG old.
Jetzthabensieihn I. schrieb: > Beim Hochfahren der Betriebsspannung muss der Resetbaustein > dann aber spätestens deutlich unterhalb von Vin = 2,7V den > ResetPin LOW halten. > Wenn Du da ein Reset-IC, am liebsten TO92 im Ärmel hast, bitte > raus damit. Woher kommen nur all diese "Weisheiten". Spannungen unter 1V sind schon lange nix Dolles mehr, da gibt es mehr als genug Teile.
batman schrieb: >> Wenn Du da ein Reset-IC, am liebsten TO92 im Ärmel hast, bitte >> raus damit. > > Woher kommen nur all diese "Weisheiten". Spannungen unter 1V sind schon > lange nix Dolles mehr, da gibt es mehr als genug Teile. Eines würde mir schon reichen. Also bitte. LG old.
Jetzthabensieihn I. schrieb: > batman schrieb: >>> Wenn Du da ein Reset-IC, am liebsten TO92 im Ärmel hast, bitte >>> raus damit. >> >> Woher kommen nur all diese "Weisheiten". Spannungen unter 1V sind schon >> lange nix Dolles mehr, da gibt es mehr als genug Teile. > > Eines würde mir schon reichen. Also bitte. > > LG > old. Meinst du sowas in der Art? Da gibts ja einiges...
Ok, ich glaube wir drehen uns im Kreis. Ich habe bereits oben verdeutlicht, dass unterhalb von 2,7V die BOD den uC "sicher" hält ...(siehe oben). Es wurde "Reset kleiner 1V" empirisch an einem Exemplar oder einer kleinen Charge vermessen. Bei welchen Temperaturgrenzen hat diese "erweiterte Qualifikation" stattgefunden? Bitte immer an die Anforderungen im Datenblatt halten, damit verabschiede ich mich vom Thema...
BUZ schrieb: > Ich habe bereits oben verdeutlicht, dass unterhalb > von 2,7V die BOD den uC "sicher" hält ...(siehe oben). Was natürlich nur dann gilt, wenn die BOD auch aktiviert werden kann (Problematik mit Batterien, s. oben). Kann sie das nicht, muss der uC mit einer externen Schaltung abgeschaltet werden, bis die Spannung hinreichend ist. Welche Bausteine kämen da in Frage?
Angehängte Dateien:
-
atmega328_reset.JPG
77 KB
BUZ schrieb: > Bitte immer an die Anforderungen im Datenblatt halten Dann mach das doch mal. 5V x 0,2 = 1V Und ich hatte bis eben nicht ins Datenblatt geschaut. S. R. schrieb: > Welche Bausteine kämen da in Frage? Da sind wir schon zu zweit. (Inzwischen habe ich aber eine arduinotaugliche Bastellösung mit zwei Transistoren.) LG old.
CO2 ist ihm N. schrieb: > Eines würde mir schon reichen. Also bitte. Damit das hier nicht unbeantwortet bleibt: Karl-werner R. schrieb: > MCP130T LG old.
Thread beobachten
Seitenaufteilung abschalten
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.