Hallo zusammen, wir haben in einer Kleinserie bislang den ATmega328P verwendet und sind nun auf die ATmega328PB Variante umgestiegen. Betrieben wird er mit einem 16MHz Quartz, vorher im FullSwing Modus und jetzt im "Low Power Crystal" Modus. In der Endfertigung bzw. im Test wird die Platine natürlich auch angefasst und wir hatten bislang keine Probleme damit. Seit der Verwendung des ATmega328PB haben wir aber mehrfach Ausfälle zu beklagen und wie es aussieht, ist das Flash kaputt (Bootloader prüft die Applikation und stellt einen Fehler fest) Nach mehreren Tests haben wir herausgefunden, dass er wohl die Berührung des Quartzes nicht so gerne mag (was ich nachvollziehen kann) und es scheint mir auch schlüssig, dass der FullSwing Modus nicht so anfällig auf Berührungen war. Was mir aber nicht einleuchten mag ist, warum dadurch das Flash zerstört wird? Wir haben zwei verschiedene Quartze getestet. Der eine führt fast immer zum kaputten Flash, der andere stoppt und in den meisten Fällen ist nach dem Restart wieder alles in Ordnung (was ich mir so auch erwarten würde) Hat jemand Erfahrung in diesem Bereich? Kann mir jemand eine 16MHz Quartz, Kondensatorempfehlung abgeben, die stabil läuft?
Werden denn die Baugruppen ESD gerechnet behandelt/verarbeitet?
Wolfgang schrieb: > Was mir aber nicht einleuchten mag ist, warum dadurch das Flash zerstört > wird? Entweder ESD oder einfach durch Glitches - dabei werden die notwendigen Schaltzeiten unterschritten und der µC macht Mist. Ja, dadurch kann Flash überschrieben oder gelöscht werden. Wolfgang schrieb: > Kann mir jemand eine 16MHz > Quartz, Kondensatorempfehlung abgeben, die stabil läuft? Ich habe schon mal Schaltungen gesehen, wo das Quarzgehäuse per kurzem Draht mit Masse verbunden wurde. Oder man nimmt eins der 4-beinigen SMD Quarze, wo die übrigen 2 "Beine" ohnehin auf Masse liegen. Ich würde mir aber auch mal anschauen ob die Arbeiter ESD Schutz tragen. "Wireless" ESD Armbänder taugen übrigens nix. ;-)
Wolfgang schrieb: > dass er wohl die Berührung des Quartzes nicht so gerne mag Ich habe seit Monaten 2 PB Schaltungen am Tisch herumliegen. Der wird vom mir richtig "befummelt" ... Da wird nichts kaputt. Was für ein Quartz ist das?
Wolfgang schrieb: > Der eine führt fast > immer zum kaputten Flash, der andere stoppt und in den meisten Fällen > ist nach dem Restart wieder alles in Ordnung Unklare Aussage. Wird der Flash zerstört und ist dadurch nicht neu programmierbar oder wird nur der Inhalt verändert sodass er neu programmiert werden muss. Kaputter Flash heist eigentlich: Kaputter Flash. Kaputt ist kaputt. Aber "zwischen den Zeilen" liest man was anderes.
Es ist ein Quartz mit zwei Beinen, allerdings die beiden freien nicht auf Masse. Sollte der ATMEGA328PB ESD empfindlicher sein, als die P Variante? Glitches wären natürlich eine Möglichkeit, daran habe ich auch schon gedacht, daher meine Frage nach Erfahrungswerten. Folgender Quartz wurde verwendet (bei diesem ist der Flash regelmäßig kaputt), von dem anderen finde ich leider keine Bezeichnung mehr. https://www.digikey.at/product-detail/de/txc-corporation/7V-16.000MAAV-T/887-1799-1-ND/3585941
Es ist ein Quartz mit !!! VIER !!! Beinen, allerdings sind die beiden freien Pins nicht auf Masse. Sollte der ATMEGA328PB ESD empfindlicher sein, als die P Variante? Glitches wären natürlich eine Möglichkeit, daran habe ich auch schon gedacht, daher meine Frage nach Erfahrungswerten. Folgender Quartz wurde verwendet (bei diesem ist der Flash regelmäßig kaputt), von dem anderen finde ich leider keine Bezeichnung mehr. https://www.digikey.at/product-detail/de/txc-corporation/7V-16.000MAAV-T/887-1799-1-ND/3585941
Wolfgang schrieb: > Hat jemand Erfahrung in diesem Bereich? Kann mir jemand eine 16MHz > Quartz, Kondensatorempfehlung abgeben, die stabil läuft? Ich würde Dir empfehlen, möglichst auf den internen Takt zu setzen und auf die Quarzgeschichte ganz zu verzichten. Einer der großen Vorteile der PBs ist doch gerade ihr wesentlich genauerer interner Takt. Ansonsten kann ich vermehrt defekte PB MCs nicht bestätigen.
Ist der Brownout-Detektor an? Ohne den hat's mir früher auch gern das Flash zerlegt. Teilweise hats sogar die Fuses getroffen, auf einmal war das Flash schreibgeschützt...
Wolfgang, würdest Du bitte die Frage beantworten >(bei diesem ist der Flash regelmäßig kaputt) >>Unklare Aussage. >>Wird der Flash zerstört und ist dadurch nicht neu programmierbar >>oder wird nur der Inhalt verändert sodass er neu programmiert >>werden muss.(?) StromTuner
Der Umstieg auf den internen Oszillator ist bei diesem Produkt leider nicht möglich, da ich die 16MHz brauche. BrownOut Detection ist an (1.8 oder 2.7V, bin gerade nicht sicher) Der Inhalt des Flashes ist zerstört und lässt sich durch erneutes Programmieren wiederherstellen.
Wolfgang schrieb: > Der Inhalt des Flashes ist zerstört und lässt sich durch erneutes > Programmieren wiederherstellen. Das ist aber was ganz anderes als "Flash kaputt". Allenfalls ist das Irreführen der Community. SCNR. Wolfgang schrieb: > führt fast immer zum kaputten Flash
Wolfgang schrieb: > BrownOut Detection ist an (1.8 oder 2.7V, bin gerade nicht sicher) Also definitiv deutlich zu gering eingestellt. Bei 16MHz braucht der Mega328PB zur einwandfreien Funktion lt. DB mindestens eine Spannung von sehr deutlich oberhalb 2.7V. Das sollte auch für [Mod: Beleidigung gelöscht] dich leicht ermittelbar sein, denn gerade der Fall 2.7V ist im Diagramm "speed grades" im DB sogar explizit eingezeichnet und zeigt als Grenzwert 10MHz... Davon mal ab: neben zu geringer Spannung kann wirklich auch unsauberer Takt den µC zu quasi stochistischem Verhalten treiben, darin ausdrücklich eingeschlossen sind "wilde" Überschreibungen eigentlich persistenter Speicherbereiche wie Flash oder EEPROM. Dagegen hilft i.A. die Verwendung tatsächlich zum Quarz, Controller und Layout passender Bürdekondensatoren. Was den Quarz und den Controller betrifft, entnimmt man die Daten einfach deren jeweiligem Datenblatt. Bezüglich des Layout kann man schätzen. Wenn's auch nur halbwegs professionell designed ist, sollte es sehr deutlich unter 5pf in's Spiel bringen... Leute, die unfähig zum DB-lesen und rechnen sind, können es allerdings auch per trial&error messen. Wenn sie denn wissen, was sie tun...
:
Bearbeitet durch Moderator
Beitrag #5000491 wurde von einem Moderator gelöscht.
Beitrag #5000515 wurde von einem Moderator gelöscht.
Hi @hater Die 'Wahrheit' kann man aber auch äußern, OHNE beleidigend zu werden. Nicht ganz einfach, wenn man nur Tanzen in der Schule hatte, nicht wahr? Du hast teilweise eine recht eigene Art an Dir. Im realen Leben solltest Du vll. doch ganz kleine Brötchen backen, da Du sonst wohl eher zu rein flüssige Nahrung 'verdonnert' wirst. Allerdings, muß ich gestehen, sind Deine (Grund-)Ansichten nicht immer weltfremd - hier hast Du das Ziel aber deutlich verfehlt. Dem Rest: MfG
Wolfgang schrieb: > Hat jemand Erfahrung in diesem Bereich? Kann mir jemand eine 16MHz > Quartz, Kondensatorempfehlung abgeben, die stabil läuft? Wie sieht das Layout für die Anbindung des Quartzes überhaupt aus? Entspricht das der Atmel App-Note AVR186: "Best Practices for the PCB layout of Oscillators" oder sind da "Fernleitungen" im Spiel? http://www.atmel.com/Images/doc8128.pdf
c-hater schrieb: > Wolfgang schrieb: > >> BrownOut Detection ist an (1.8 oder 2.7V, bin gerade nicht sicher) > > Also definitiv deutlich zu gering eingestellt. > > Bei 16MHz braucht der Mega328PB zur einwandfreien Funktion lt. DB > mindestens eine Spannung von sehr deutlich oberhalb 2.7V. Das gilt auch schon für den 328P und der funktioniert ja nach Bekunden des TE. Die Sinnhaftigkeit des BrownOut-Setups dahingestellt- es ist zudem keine Aussage über die tatsächlich verwendete Betriebsspannung.
Der BOD ist nicht richtig eingestellt, was aber erfahrungsgemäß nicht zur "Umprogrammierung" des Flash führt. Mit anderer Schaltschwelle wird sich schnell zeigen, daß hier keine Verbesserung eintritt. Wenn das Problem bei der Handhabung auftritt, sind vermutlich elektrostatische Entladungen im Spiel, auf die der ..PB empfindlicher reagiert.
Naja beim EEPROM hatte ich zumindest reproduzierbar Datenverlust schon beim reinen Lesezugriff am Start ohne BOD. Warum solls sowas nicht auch beim Flash geben. Momentan habe ich auch unerklärte Komplettausfälle bei reiner ISP-Komm. Der AVR, das unbekannte Wesen.
batman schrieb: > Momentan habe ich auch unerklärte > Komplettausfälle bei reiner ISP-Komm. Der AVR, das unbekannte Wesen. Zur Kommunikation gehören immer zwei :-) m.n. schrieb: > Wenn das Problem bei der Handhabung auftritt, sind vermutlich > elektrostatische Entladungen im Spiel, auf die der ..PB empfindlicher > reagiert. Also mir hat noch NIE einer der seit über 10 Jahren zahlreich verwendeten Typen Probleme in der Handhabung bereitet. Und dabei zähle mich eher zu den tapsigen Bastler-Grobmotorikern ( meist mit Plastik-Badelatschen)!
Daniel Fiebig schrieb: > Also mir hat noch NIE einer der seit über 10 Jahren zahlreich > verwendeten Typen Probleme in der Handhabung bereitet. Laß mich raten: einen 328PB hast Du noch nie verwendet, insbesondere nicht vor 10 Jahren.
m.n. schrieb: > Laß mich raten: einen 328PB hast Du noch nie verwendet, insbesondere > nicht vor 10 Jahren. Irrtum. Der ist gerade mein Mädchen für (fast) alles :-)
Wenn alle Ports beschaltet sind, zumindest mit internem Pullup, spielt der Quarz dann vielleicht keine Rolle mehr. Man siehts oft nur am 100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine 50Hz Welle o.ä. empfangen.
Hi >Man siehts oft nur am >100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >50Hz Welle o.ä. empfangen. Gibt es für diesen Wert auch belastbare Quellen? MfG Spess
Wolfgang schrieb: > In der Endfertigung bzw. im Test wird die Platine natürlich auch > angefasst und wir hatten bislang keine Probleme damit. Meinst Du damit, im Betrieb angefaßt oder spannungslos. Im Betrieb sollte man den Quarz nicht irritieren. Wenn es bisher gut ging, ist das nur Glück. Sofern der Nutzer nicht auf den Quarz fassen können muß, sollte das auch der Endtest gefälligst sein lassen. Mal den Leuten gehörig auf die Finger klopfen.
spess53 schrieb: > Hi > >>Man siehts oft nur am >>100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >>50Hz Welle o.ä. empfangen. > > Gibt es für diesen Wert auch belastbare Quellen? > > MfG Spess Für mich ja. Gestern am Mega8 im Powerdown 380µA gemessen, mittels Anfaßtest (andere Hand an GND oder Vcc) den schuldigen offenen Port (RxD nicht verbunden) gefunden (Strom fällt bei Berührung schlagartig ab). Nach gesetztem Pullup dann <2µA.
spess53 schrieb: > Hi > >>Man siehts oft nur am >>100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >>50Hz Welle o.ä. empfangen. > > Gibt es für diesen Wert auch belastbare Quellen? > > MfG Spess Ein Eingang am Mikrocontroller verhält sich gleich wie ein CMOS-Gatter: https://www.fairchildsemi.com/application-notes/AN/AN-77.pdf auf Seite 5, Figure 5d und Text. Ähnliche Dokumente gibt es auch von anderen Herstellern. Die Stromangaben variieren, da auch der Herstellungsprozess anders ist. Allerdings spielt es sich meist mA Bereich ab, dass ist für CMOS bei statischen Bedingungen eine Menge.
@Daniel Wir reden hier von der 328PB, nicht von der P Version!
Hi >Ähnliche Dokumente gibt es auch von anderen Herstellern. Die >Stromangaben variieren, da auch der Herstellungsprozess anders ist. >Allerdings spielt es sich meist mA Bereich ab, dass ist für CMOS bei >statischen Bedingungen eine Menge. Hier im Forum hat das hat das vor einigen Jahren mal jemand gemessen. Da lag der Mehrverbrauch bei offenen Pins im unteren zweistelligen µA-Bereich. MfG Spess
Hängt wohl von der Frequenz ab und ob der Port überhaupt voll durchschwingt und was intern dranhängt und und..
spess53 schrieb: > Da lag der Mehrverbrauch bei offenen Pins im unteren zweistelligen > µA-Bereich. Wie willst du das so pauschal vergleichen? Das Potential an einem offenen Pin hängt davon ab, wo er sich auf Grund irgendwelcher layoutbedinger Leckströme potentialmäßig hin legt. Im worst-case sind beide FETs gleichzeitig leitend und es kommt zu den Querströmen im mA-Bereich. Außerdem gibt es außer diesem statischen Effekt auch noch den dynamischen durch Umladeströme auf Grund von eingefangene Störsignale.
spess53 schrieb: > Hi > >>Man siehts oft nur am >>100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >>50Hz Welle o.ä. empfangen. > > Gibt es für diesen Wert auch belastbare Quellen? > > MfG Spess spess53 schrieb: > Hier im Forum hat das hat das vor einigen Jahren mal jemand gemessen. Da > lag der Mehrverbrauch bei offenen Pins im unteren zweistelligen > µA-Bereich. Gibt es für diesen Wert auch belastbare Quellen? ;)
Wolfgang schrieb: > Folgender Quartz wurde verwendet (bei diesem ist der Flash regelmäßig > kaputt), von dem anderen finde ich leider keine Bezeichnung mehr. Der hat nur 8pF Lastkapazität. Ohne Masseverbindung daher empfindlich - und vermutlich sind die Lastkondensatoren zu groß, denn die sollten IMHO nur so 10-12pF haben. Vermutlich hat der nur eine relativ kleine Amplitude, dann werden sehr leicht bei Kontakt o.g. Glitches produziert. Eventuell fallen die dadurch auch durch den EMV Akzeptanz Test, aber YMMV. Probiere mal ggf. kleinere Lastkondensatoren und eine Masseanbindung des Gehäuses per Fädeldraht über eins der unbenutzten Pads.
Habe jetzt nochmal geprüft, die BOD ist auf 2.7V eingestellt. 4.3V war mir zu knapp an der Versorgungsspannung und hat teilweise schon bei Stromspitzen ausgelöst (akkuversorgte Anwendung) Nochmal zur Klarstellung: nicht das Flash selbst, sondern der Flashinhalt ist korrupiert. Die Leitungen zwischen Quarz und Controller sind so kurz wie möglich. Wir hatten bislang 4pF und 10pF getestet, mit ähnlichem Ergebnis. ESD-induzierte Fehler, können mMn ausgeschlossen werden, da der Fehler einigermaßen reproduzierbar ist (Berührung am Quarzpin) und nicht auftritt, wenn andere Pins berührt werden. (wir haben recht intensiv gefummelt und bis auf diesen einen Pin, ist nichts passiert) Der Kunde kommt an die Platine gar nicht ran, aber es beunruhigt mich trotzdem, dass unsauberer Takt zu zerstörtem Flashinhalt führt, zumal die Applikation im Regelfall nicht schreibend auf das Flash zugreift.
Kein ESD, das heißt, das passiert auch, wenn die andere Hand geerdet ist und man diese Pins anfasst? Was passiert, wenn man einen der Pins des Quarzes im Betrieb kurz (hoch/niederohmig) auf Masse zieht?
Wolfgang schrieb: > zumal die Applikation im Regelfall nicht schreibend auf das Flash zugreift. Aber einen Bootloader habt Ihr drin?
Horst M. schrieb: > Aber einen Bootloader habt Ihr drin? Ich würde mal den Bootloader rausnehmen, ob der Flash sich dann immer noch löscht. Es kann gut sein, daß bei zu geringer Pulsweite des CPU-Taktes Befehle falsch ausgeführt werden und irgendwo in den Bootloader gesprungen wird. Man kann dem abhelfen, indem beim regulären Sprung in den Bootloader ein Magic (0xA5) in eine Variable geschrieben wird und diese direkt vor jedem SPM getestet wird.
Horst M. schrieb: > Aber einen Bootloader habt Ihr drin? Jetzt wird es aber merkwürdig. Vielleicht werden auch float-Routinen verwendet, was den Flash so instabil macht?
m.n. schrieb: > Vielleicht werden auch float-Routinen verwendet, was den Flash so > instabil macht? Kannst du das bitte etwas näher erläutern?
Wolfgang schrieb: > Wir hatten bislang 4pF und 10pF getestet Das wird normalerweise berechnet, nicht getestet. Was hast du sonst so probiert?
Wolfgang schrieb: > im Regelfall nicht schreibend auf das Flash zugreift Verrätst du uns, welchen Bootlader ihr einsetzt? Wird der Bootlader grundsätzlich nach Reset aktiv oder muss er zusätzlich über einen Jumper aktiviert werden?
Wolfgang schrieb: > Wir hatten bislang 4pF und 10pF getestet, mit ähnlichem Ergebnis. Kommt mir sehr wenig vor. Ich benutze am AT90CAN128 ein 16MHz Quarz mit 2*22pF und habe keine Schwingprobleme. Im AVR-Datenblatt steht ja 12..22pF. Die beiden Pins, die auf dem Gehäuse liegen, habe ich nicht angeschlossen. In den Quarz-Datenblättern sind die auch mit NC angegeben. Im Vorgänger mit dem AT89C51CC03 waren es 20MHz mit 2*33pF.
Peter D. schrieb: > Im AVR-Datenblatt steht ja 12..22pF. Das hängt ja vom Quartz ab, nicht? IMHO braucht er 12-15pF aber an dem dürfte es nicht gelegen haben...
Wie sieht die Programmiersequenz aus? Wenn bootloader, wie kommt der bootloader rein? Welche Tools zur Programmierung werden verwendet? Hintergrund: ich hoffe ihr verwendet nicht einen jtagicemkii oder andere "evaltools". Diese sind nicht produktionsgeeignet. Wie sieht die Powerup/down Sequenz vor dem Flashen/nach dem Flashen aus? Werden auch alle Datenblatt Parameter beachtet? Speziell der Wert "Power-on Reset Threshold Voltage (falling)" (muß wenn die Spannung abgestellt wird unter 0.6V fallen, falls jemand z.b. das Board ein-aus-ein schaltet, und das nicht schnell genug passiert, dann sind wir schon im "nicht-spezifizierten" Bereich und da kann alles passieren.
Und wie ist der Reset-Pin im fertigen Gerät nach dem Programmieren beschaltet? Pullup RC oder nur Pullup R oder hart mit VCC verbunden oder völlig offen?
Hi >spess53 schrieb: >> Hier im Forum hat das hat das vor einigen Jahren mal jemand gemessen. Da >> lag der Mehrverbrauch bei offenen Pins im unteren zweistelligen >> µA-Bereich. >Gibt es für diesen Wert auch belastbare Quellen? >;) Für mich ja. Ich habe es heute mal selbst gemessen (ATTiny84, 10R Shunt in der +Leitung und Keysight 34462A Multimeter). Da komme ich auf 150µA Mehrverbrauch bei offenen Pins (DDRA/B und PORTA/B auf 0x00) und Pins mit eingeschalteten Pull-Up-Widerständen. Bei 12 Pins macht das 12,5µA/Pin. Das deckt sich mit meiner Erinnerung. Den erwähnten Beitrag habe ich nicht mehr gefunden, ist aber schon ein paar Jahre her. MfG Spess
Stefan schrieb: > Hintergrund: ich hoffe ihr verwendet nicht einen jtagicemkii oder andere > "evaltools". Diese sind nicht produktionsgeeignet. Na ja, wenn das Pogramm fehlerfrei im Flash gelandet ist (und das ist hier der Fall), ist es völlig egal, womit das programmiert wurde. Oliver
Oliver S. schrieb: > Na ja, wenn das Pogramm fehlerfrei im Flash gelandet ist (und das ist > hier der Fall), ist es völlig egal, womit das programmiert wurde. Bist du dir sicher? Wenn während des flash Vorgangs jemand das Board berührt, ist es ausgeschlossen dass Fehler im Flash verzögert aufkommen?
Verzögert kippende Bits? Klingt sehr komisch, und ist wohl auch so. Außerdem gings um das geeignete Programmiergerät, nicht um Berührung während des Programmierens. Oliver
spess53 schrieb: >>Man siehts oft nur am >>100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >>50Hz Welle o.ä. empfangen. > > Gibt es für diesen Wert auch belastbare Quellen? Es ist common sense, einen CMOS-Eingang niemals floaten zu lassen. Warum, das wurde ja schon genannt. Dazu noch eine Ergänzung: Das gilt ausnahmslos für ALLE IC, außer es ist im Datenblatt expliziet erlaubt. Was man bei einem µC tun kann: - Den Port auf OUT stellen und LOW oder HIGH treiben - Pullups/Pulldowns aktivieren Pferdefuß dieser Methode: Im Reset darf der dann nicht zulange rumdümpeln. Ich habe von einem FAE eines µC-Hersteller direkt die Antwort bekommen: Wenn das so ist (µC lange im Reset) sind externe Pulls zwingend. Heißt: Ein- und Ausschalten (!) der Versorgung müssen kontrollierte Verläufe haben. Ist das nicht so -> Pullups fällig. Ähnliches ist übrigens auch der Grund, warum viele IC eine Min und Max Spannungsrampe im Datenblatt haben. Ein guter Entwickler baut seine Versorgugen aber eh so, das geht heute gratis mit, danke "precisision enable", "Undervoltage Lockout" und PGOOD-Pins. Wenn man denn moderne Spannungsregler verwendet ;-)
spess53 schrieb: > Für mich ja. Ich habe es heute mal selbst gemessen (ATTiny84, 10R Shunt > in der +Leitung und Keysight 34462A Multimeter). Da komme ich auf 150µA > Mehrverbrauch bei offenen Pins (DDRA/B und PORTA/B auf 0x00) und Pins > mit eingeschalteten Pull-Up-Widerständen. Mit eingeschalteten Pullup-Widerständen?? Dann sind das keine offenen Pins. Ein Pullup-Widerstand dient genau dazu, den (eigentlich verbotenen) Zustand eines offenen Pins zu verhindern und diesen auf ein festes Potential zu ziehen. Um den worst-case zu simulieren, leg alle offenen Eingänge über 1 kOhm an VDD/2, bei einem 5 V-Controller also auf 2,5 V. Dann sind alle Eingangstransistoren halb durchgesteuert und ziehen maximalen Querstrom.
Hi >Es ist common sense, einen CMOS-Eingang niemals floaten zu lassen. >Warum, das wurde ja schon genannt. Na ja, wenn dein 'common sense' nicht weiter reicht. Bei mir sind seit 20 Jahren alle nicht benutzten Pins von AVRs weder als Ausgang noch mit internem Pull-Up-Widerstand beschaltet, also floatend. Und diese AVRs sitzen in in Steuerungen von Geräten im Wert aufwärts von Kleinwagen bis hin zu Mehrfamilienhäusern und das auf allen, evtl. ausser Australien, Kontinenten. Mit eurer Panikmache könnt ihr vielleicht kleine Kinder oder blutige Anfänger erschrecken aber niemanden, der sich auskennt. MfG Spess
soul e. schrieb: > Um den worst-case zu simulieren, leg alle offenen Eingänge über 1 kOhm > an VDD/2, bei einem 5 V-Controller also auf 2,5 V. Dann sind alle > Eingangstransistoren halb durchgesteuert und ziehen maximalen Querstrom. Noch lustiger: Häng die Schaltung an ein Labornetzgerät, und dreh die Spannung von 0 weg langsam (sehr langsam!) auf und miss den Strom. Interessant ist alles was unter der Min. Recommendet Spannung passiert ;-)
spess53 schrieb: >>Man siehts oft nur am >>100fachen Ruhestromverbrauch, wenn unbenutzte Eingangsports gerade eine >>50Hz Welle o.ä. empfangen. > > Gibt es für diesen Wert auch belastbare Quellen? Eher nicht, 50Hz haben tatsächlich bei weitem nicht die Macht, das zu schaffen. Eine relativ starke 50Hz-Einstreuung kann unter günstigen Umständen sogar im Gegenteil dafür sorgen, daß sich der Schaden energieverbrauchsmäßig stark in Grenzen hält. Ist ja fast DC und verhält sich auch so. Die wahren Energieräuber (richtige HF) kann dann nur noch in den schmalen Bereichen zuschlagen, bei denen die 50Hz-Störung in der Nähe des Nullpunktes ist. Aber ein offener Eingang ist definitiv wie dafür gemacht, alles Mögliche aus der Umgebung aufzusaugen wie ein Schwamm. Kein Mensch wird es sich freiwillig antun, die Impedanzen und Pegel aller möglichen Störquellen zu ermitteln, um die Folgeschäden kompetent abschätzen zu können, wenn der eine Leiterzug/Widerstand, der nötig ist, um den Pin niederohmig auf ein definiertes Potential weit weg vom Umschaltbereich zu hieven, so billig ist... Zumal es in den meisten normalen Anwendungsfällen vollkommen genügen dürfte, einfach die Pullups für unbenutzte Pins zu aktivieren, d.h. nicht einmal irgendein Hardwareaufwand entstehen würde...
spess53 schrieb: > Bei mir sind seit > 20 Jahren alle nicht benutzten Pins von AVRs weder als Ausgang noch > mit internem Pull-Up-Widerstand beschaltet, also floatend. Das ist definitiv nicht gut. Schon in häuslicher Umgebung kann das heutzutage relativ leicht dazu führen, daß alle diese Pins ständig mit der Frequenz irgendeines verschissenen LED-Dimmers oder SNT toggeln. Und in industrieller oder automotive-Umgebung ist es "tödlich". Nur bezüglich des unnützen Energieverbrauchs natürlich, die eigentliche Funktion wird davon i.d.R. nicht beeinflusst werden. > Und diese > AVRs sitzen in in Steuerungen von Geräten im Wert aufwärts von > Kleinwagen bis hin zu Mehrfamilienhäusern und das auf allen, evtl. > ausser Australien, Kontinenten. Und keins davon ist batteriegespeist, stimmt's?
Oliver S. schrieb: > Verzögert kippende Bits? Klingt sehr komisch, und ist wohl auch > so. Ist es ganz und gar nicht. Google mal nach margin verify, das ist ein sehr bekanntes Problem, wenns um massenfertigung und lange lebensdauer geht. Und es passiert auch wirklich, abhängig von spannung, temperatur, alter der zelle..
HI >Und keins davon ist batteriegespeist, stimmt's? Ja. Da kommen Trafos zu Einsatz gegen die Schweißtrafos etwas spielzeugartiges haben. >Und in industrieller oder automotive-Umgebung ist es "tödlich". Nur >bezüglich des unnützen Energieverbrauchs natürlich,... Der spielt bei Anschlussleistungen größer zweistelligen kW-Bereich keine Rolle >die eigentliche Funktion wird davon i.d.R. nicht beeinflusst werden. Das sagt indirekt selbst Atmel. MfG spess
Ich habe die letzten Jahre relativ viel Ultra-Low-Power Elektronik gebaut (also Sachen, die 2µA im sleep benötigen dürfen oder so), und da haben mir offene Pins oft den Tag versaut. Es reicht ein einziger, und man bekommt nicht reproduzierbare Resultate. Einmal passt die Stromaufnahme, ein anderes mal ist sie wieder zu "hoch". Wenn man mit der Hand 20cm oberhalb des Boards vorbeifährt, geht die Stromaufnahme "hoch". "hoch" ist in "", weil wir da von <50µA reden. Das wird den Controller nicht töten können. Man kann aber davon ausgehen, dass wen nur ein einzelner Port undefiniert ist, man niemals die Stromaufnahmen aus dem Datenblatt erreichen wird. --> Weil einen offenen Port LOW treiben oder Pullup einschalten genau 0,0000€ kostet, tut man das einfach.
CyberangriffstruppeVollbit schrieb: > --> Weil einen offenen Port LOW treiben oder Pullup einschalten genau > 0,0000€ kostet, tut man das einfach. Es kostet Entwicklungszeit und in der Regel ist die geplante Zeit eh schon überschritten und der Versand hat das Gerät schon halb eingepackt, eh Du Deine Tests abgeschlossen hast. Da ist keine Zeit, sich den Schaltplan zu nehmen, die unbenutzten Pins rauszusuchen, die init.c zu ergänzen und nochmal alles zu testen, ob man keine Schusselfehler eingebaut hat. Bei Netzbetrieb interessiert es niemanden, ob der AVR nun 10mA oder 20mA verbraucht. Die Netzsicherung spricht darauf nicht an.
Peter D. schrieb: > Es kostet Entwicklungszeit Bei uns geht das GRATIS mit: Pinplanung macht das der Hardwareentwickler bei der Schaltplanerstellung. Planen muss der ja sowieso, denn irgendwer muss ja festlegen, welcher Pin die UART1_RX ist und so weiter. Wenn man sich ein bisserle auskennt, hüpft da gleich der richtige Header dabei heraus. Ohne Mehraufwand. Den Rest erledigt eine Initfunktion. Aufwand: 0,0. Da hat auch einen Grund: Wir hatten nämlich einen Servicefall, mit einer Firmware, die einen Interrupt auf einen offenen Pin hängen hatte. Im Haus (und bei 99% der Kunden) lief das problemlos. Bei einem Kunden nicht. Auch dieverse falsch konfigurierte UARTs gabs schon.
Ist sicher auch nicht so schön, wenn sich sporadisch von mehreren Porttreibern parallel verstärkte HF auf die Vcc überlagert. Zumindest wenn der µC analoge Werte im unteren mV-Bereich sampelt.
Wo ist das Problem Ports aktiv zu ziehen/Pullups einzuschalten an unbenutzten Pins? Bei mir in de Firma gibts ein Checkliste für Design-Reviews, wo auch die Behandlung unbenutzter Pins angeführt ist. Darann hat sich jeder Entwickler zu halten, egal ob das offenlassen der Pins theoretisch keine Auswirkung in der Anwendung hätte. Wenn man einen negativen Effekt durch eine einfachste Maßnahme verhindern kann, dann macht man das auch. Wenn das beschreiben der Port-Register der offenen Pins eine signifikate Auswirkung auf die Entwicklungszeit hat, dann ist jemand einfach ungeeignet.
Mr M. schrieb: > Bei mir in de Firma gibts ein Checkliste für Design-Reviews, kannst du uns so eine Liste zur Verfügung stellen?
Hi >Wenn das beschreiben der Port-Register der offenen Pins eine signifikate >Auswirkung auf die Entwicklungszeit hat, dann ist jemand einfach >ungeeignet. Da bin ich wirklich heilfroh, das unser Chef dem gesunden Menschenverstand vertraut und nicht wir keine Leute in der Firma haben die sich 'Mr Mat (racecobra)' nennen. MfG Spess
Hi
>Was, keinen einzigen? Seltsame Firma.
Vielleicht weil niemand dein Gestammel verstanden hat?
MfG Spess
Wolfgang schrieb: > Hat jemand Erfahrung in diesem Bereich? Kann mir jemand eine 16MHz > Quartz, Kondensatorempfehlung abgeben, die stabil läuft? Ich verwende gerne Keramikresonatoren, die brauchen nichts weiter und sind günstig (1000 Stück für etwa 20$). Trotzdem gehe ich davon aus, dass ein Quarzoszillator weniger störanfällig, weniger temperaturabhängig und genauer/stabiler ist. Wolfgang schrieb: > Der Kunde kommt an die Platine gar nicht ran, aber es beunruhigt mich > trotzdem, dass unsauberer Takt zu zerstörtem Flashinhalt Der 328PB ist sehr robust und dass ein mieser Oszillator den Flashinhalt ändert/löscht klingt ungewöhnlich. Bei 16MHz gilt: @ 4.5 - 5.5V Außerdem sollten die Fuses richtig gesetzt sein (...). Wenn Du die Möglichkeit hast, teste mal nur den µC + Oszillator + Versorgung ohne weitere Baugruppen auf der gleichen Platine. Möglicherweise kann man das Boardlayout verbessern.
Die Software verwendet einen selbstgestrickten Bootloader. Nach dem PowerUp wird er angesprungen, die Checksumme der Applikation getestet und falls diese i.O. ist wird ein SoftwareReset Vector angesprungen. Die Reset Leitung ist per Fuse deaktiviert, ebenso ISP. Ich möchte nicht ausschließen, dass durch Glitches schreibender Code angesprungen wird, dass dies so reproduzierbar passieren soll, wundert mich aber doch sehr. Wir haben nun unterschiedliche Quarz-Kondensator Kombinationen (Quarze Lastkapazität 9-18pF, externe Kondensatoren 4-22pF) getestet und ein erstaunliches Ergebnis: ALLE Kombinationen funktionierten. Der aktuelle Verdacht ist, dass die Quarze nicht sauber bestückt sind. :-/ Wir testen gerade, ich melde mich wieder. Bitte seid so nett, und klärt bilateral, ob ihr eure PullUps einschaltet oder nicht, denn das interessiert in diesem Beitrag niemanden.
Wolfgang schrieb: > durch Glitches schreibender Code > angesprungen Wie wäre es mit der Annahme, dass ein Reset ungewollt ausgelöst wird? Durch Berühren des Quarzes reisst der Oszillator ab und dann passiert es. Ist der Wachhund an der Kette oder frei? Mach doch einfach mal im Bootlader ganz am Anfang für 200ms eine LED an. Dann kannst du diesen Verdacht uU schon mal ausschliessen.
Woher stammen die 328PB? Nicht das ihr da Fakes verbaut habt, und somit an der falschen Stelle sucht!
Also an den Lötstellen liegt es auch nicht... Die Chips sind von Digikey und wir haben gleich mal 2 Trays davon gekauft. Watchdog verwenden wir keinen. Das mit der LED im Bootloader haben wir genauso gemacht. Leider ist uns jetzt auch ein Controller während des Betriebs gestorben. Das kam bei den ATMEGA328P nicht vor. Echt ärgerlich und ich habe nach wie vor keinen Plan, woran es liegt. Nächste Woche werde ich mir mal die Spannungsversorgung mit dem Oszi anschauen. Nicht das wir Unterspannung haben und die PB Variante da empfindlicher ist (16MHz und keine 5V)
Poste mal den Schaltplan und die Layoutfiles. Ich vermute du hast einen PortPin an Masse und interne PullUps an.
Oder einen Schaltregler auf dem Board. Mach mal ein Detailfoto von ober und Unterseite!
:
Bearbeitet durch User
Wolfgang schrieb: > Nächste Woche werde ich mir mal die Spannungsversorgung mit dem Oszi > anschauen. Das ist ne gute Idee! MfG Klaus
Nur so als Randbemerkung, aus dem Datenblatt: When applying an external clock, it is required to avoid sudden changes in the applied clock frequency to ensure stable operation of the MCU. A variation in frequency of more than 2% from one clock cycle to the next can lead to unpredictable behavior. If changes of more than 2% is required, ensure that the MCU is kept in Reset during the changes. Das gleiche gilt natürlich auch bei einem per Quarz erzeugten Takt. Und bei Berührung des Quarzes passiert vermutlich Schlimmes. Häng doch mal ganz lose ein Scope an XTAL2 und sieh dir an, was da passiert. Wenn da mal kurz der Oszillator abreisst und neu anschwingen muss, könnte das tödlich sein.
Controller im Betrieb gestorben heißt aber diesmal Hardware-Defekt, oder?
Georg G. schrieb: > Und bei Berührung des Quarzes passiert vermutlich Schlimmes. Eigentlich passiert da nichts. Die sind in der Regel geerdet.
Richard B. schrieb: > Georg G. schrieb: > Und bei Berührung des Quarzes passiert vermutlich Schlimmes. > > Eigentlich passiert da nichts. > Die sind in der Regel geerdet. Sind sie in der Regel nicht! Hc49smd
Richard B. schrieb: > Eigentlich passiert da nichts. > Die sind in der Regel geerdet. Sind sie nicht. Normalerweise ist das Metallgehäuse des Quarzes "floating", also mit keinem Potential der Schaltung verbunden. Man kann es mit einem beliebigen Supply-Potential verbinden (vorzugsweise natürlich GND), aber das bringt eigentlich für alle normalen Anwendungsfälle rein garnix. Im Gegenteil: wenn die Dimensionierung der Oszillatorschaltung derart Scheisse ist, dass ein Berühren des Quarzgehäuses sie nennenswert aus dem Tritt bringt, dann würde eine feste Verbindung mit einem Supply-Potential wohl vor allem nur für eins sorgen: dass sie von vornherein erst garnicht anschwingt... Sozusagen die Wirkung des Antippens fest eingebaut...
@Alex Er verwendet aber keine HC49SMD, sondern-> Wolfgang schrieb: > Es ist ein Quartz mit zwei Beinen, allerdings > die beiden freien nicht auf Masse. 4 Beiner werden mit der Masse verbunden (Hersteller-Angabe). Das machen sogar die Billigheimer in China so.
Harald Umlaut schrieb: > Controller im Betrieb gestorben heißt aber diesmal Hardware-Defekt, > oder? Vermutlich ist die Aussage in die gleiche Kategorie einzuordnen wie "ATmega328PB nach Berührung Flash kaputt"...
Vielen Dank für die vielen guten Antworten. Verzeihung, du mir noch nie ein Atmel durch HW-Defekt ausgefallen ist, bin ich da wohl etwas locker in der Formulierung: FLASH DEFEKT kein HW Defekt. Wahrscheinlich werde ich jetzt gleich zerfleischt: nein, die anderen beiden Beine des Quarzes sind nicht auf Masse. Ich habe damals eines der Eagle Standardbauteile verwendet und da waren die Pins eben nicht Masse. Werde ich fürs nächste Mal aufnehmen. Zur HW: Kein Schaltregler, Pin auf Masse und interner PullUp ein macht Probleme?! Ist aber ebenfalls nicht der Fall. Die Platine wurde schon quasi leergeräumt: Glättungsspule für den ADC ersetzt durch eine Brücke, OPV weg, TVS weg, es ist nur mehr der Controller und ein paar passive Bauteile, die für den OPV Filter notwendig waren. Nur zur Erinnerung: selbe HW, gleiche Bauteile, gleiche Firmware läuft problemlos mit einem ATMEGA328P Wie hoch ist die Wahrscheinlichkeit, dass meine Charge an Controllern einfach Schrott ist?
Merkwürdig wäre daran, dass die Charge nur diesen speziellen Fehler hat. Also quasi vorselektiert auf vergesslichen Flash? Unwahrscheinlich. Wenn, dann würde ich bunt gemischt verschieden defekte Chips erwarten. Lässt sich denn nachvollziehen, ob der Bootloader Amok läuft oder ob es etwas anderes ist? Also mal ganz ohne einen Bootloader versuchen, d.h. auf dem ganzen Flash darf keine Routine sein, die den Flash beschreibt (und die durch einen Fehler angesprungen wird).
Das ist natürlich ein guter Punkt! Ich habe die Firmware schon auch wieder ausgelesen und es war eine Page relativ weit vorne gelöscht (meine Software - Interrupt Vektoren dummerweise) und das wirklich interessante: die WriteFlash Methode in der letzten Page des Controllers war ebenfalls gelöscht. Zu der Clock Variation mit den 2% noch: müsste davor nicht CFD schützen? Aber angenommen, es würde die WriteFlash Methode aufgrund von Glitches angesprungen wurden. Was lernen wir daraus?
Da viele Tips gegeben wurden, läuft der Rest nur noch auf ein kollektives Ratespiel hinaus! Das macht keinen Sinn mehr! Poste bitte die Eagle-Files und die Sourcen deiner Firmware! Alles andere führt hier zu nichts mehr! Es gab mal einen Schaltregler-Thread. Da wurde bis ins Kleinste das Layout von der Community verbessert! Alles sind jetzt zufrieden!
Wolfgang schrieb: > Nur zur Erinnerung: selbe HW, gleiche Bauteile, gleiche Firmware läuft > problemlos mit einem ATMEGA328P Aller funktionellen- und Codekompatibilität zum Trotz möchte ich mal an die Aussage in http://www.atmel.com/Images/Atmel-42559-Differences-between-ATmega328P-and-ATmega328PB_ApplicationNote_AT15007.pdf erinnern: "ATmega328PB is not a drop-in replacement for ATmega328 variants, but a new device." > Wie hoch ist die Wahrscheinlichkeit, dass meine Charge an Controllern > einfach Schrott ist? Man soll nichts ausschließen, aber ich würde sagen sie geht (zumal bei dieser Bezugsquelle) gegen Null.
Ja, klar, du hast halt z.B. beim PB auch je einen GND/VCC weniger durch die zusätzlichen Portpins. Je nach Layout(fehlern) kann sich das im ungünstigsten Fall auch zu einem EMV-Problem entwickeln.
Es dürfte eher der Wegfall des FullSwing- bzw. der Wechsel zum LowPower Crystal Mode von Bedeutung sein. Was hindert daran, hier mal das bereits angesprochene neue PB-Feature CFD=Clock Failure Detection mechanism via Fuse zuzuschalten und zu sehen, ob es weiterhin zu jenen ominösen Flash-Löschungen kommt?
So schön wie die PB-Teile auch sein mögen, für Quarzbetrieb zumindest an der 16 MHz Oberkante sind sie nur eingeschränkt bzw. mit erhöhten Design-Anforderungen verwendbar. Auch im Datenblatt wird ja die verstärkte Empfindlichkeit des LowPower Crystal Osz. vermerkt. Die neue CFD wird daher nicht umsonst drin sein!
Wie ist denn eigentlich der Quarz an den µC angebunden? Oder vielmehr, wie sind die pF-Kerkos angebunden? Deren Masserückführung sollte ja auch keine große Fläche aufspannen. http://www.lothar-miller.de/s9y/categories/33-Quarz
Quarz ist nicht gleich Quarz. Der 328PB stellt scheinbar hohe Anforderungen. Da sich das Datenblatt darüber ausschweigt, sollte man den FAE von Atmel fragen. Als Test kann man einen Quarz im größeren Gehäuse (HC48) ausprobieren. Die sind iA besser im ESR. Und dazu dann die Kondensatoren deutlich verkleinern (10pF). Die Kapitel über den Quarz Oszillator sind derart weich geschrieben, dass sich jedem Entwickler mit einigen Jahren Erfahrung abrupt die Nackenhaare sträuben. Tröstlich ist, dass mit dem neuen Oszillator diverse Leute Probleme haben, der TO ist nicht allein.
Nicht ohne Grund lässt man üblicherweise den Quarzhersteller die Oszillatorschaltung auslegen und freigeben. Nicht den Controller-Hersteller.
Daß er mit holprigen Quarz mal abschmiert, mag ja gern vorkommen. Das dürfte u.a. im Batteriebetrieb, wenn irgendwann die Spannung einbricht, kaum zu vermeiden sein. Daß ein AVR Speicher löscht, die auf eine Retention >20y ausgelegt sind, ist für mich der Witz. Ich habe auch schon ein paar, relativ wenige tote Käfer liegen, die eigentlich nur durch irgendwelche internen Fehltritte verreckt sein können. Inpunkto Datensicherheit scheint es bei den Dingern Verbesserungspotential zu geben.
Alex W. schrieb: > Mr M. schrieb: >> Bei mir in de Firma gibts ein Checkliste für Design-Reviews, > > kannst du uns so eine Liste zur Verfügung stellen?
batman schrieb: > aß ein AVR Speicher löscht, die auf eine Retention >20y ausgelegt sind Was hat Speicherlebensdauer mit gewolltem Löschen zu tun? Der Käfer läuft Amok und zerschiesst sich den Speicher. Ich würde mal das Programm solo aufspielen, ohne Bootlader, und dann testen. Es wäre nicht der erste Bootlader, der bei passender Anregung etwas anders als gewollt arbeitet. Aber das sind nur Vermutungen, der TO muss messen. Wir können ihm hier nur Tipps geben.
Natürlich ist nur das ungewollte Löschen ein Problem. Darum ging es.
batman schrieb: > Daß ein AVR Speicher löscht, die auf eine Retention >20y ausgelegt sind, > ist für mich der Witz. Ich habe auch schon ein paar, relativ wenige tote > Käfer liegen, die eigentlich nur durch irgendwelche internen Fehltritte > verreckt sein können. Das ist erstmal eine Behauptung. Im Moment sieht es danach aus, dass der chip außerhalb der Spec betrieben wird. Bisher hat der TO weder ein Schematic und Layout, noch den Sourcecode zur Überprüfung gezeigt, noch ist er direkt auf verschiedene Hinweise insofern eingegangen, dass diese ausgeschlossen werden können. Zb. Welche Programming Tools verwendet werden, wie die Produktion genau abläuft, ob Vpot falliing Werte in der Spec liegen, bootloader weglassen usw.
Stefan schrieb: > Bisher hat der TO weder ein Schematic und Layout, > noch den Sourcecode zur Überprüfung gezeigt, noch > ist er direkt auf verschiedene Hinweise insofern eingegangen, > dass diese ausgeschlossen werden können @TO Würdest du dein Code hochladen, könnte ich überprüfen ob das bei mir genauso abläuft, wie bei dir.
:
Bearbeitet durch User
Hab jetzt über den Thread geschaut aber eher wenig Informationen gefunden. Welche Werte wurden für die Fusebits verwendet? Welche Kondensatoren sind am Quarz? Wie sieht die Beschaltung vom Quarz aus? Bild! Bei einem 4-pinner die beiden zusätzlichen Pads nicht an GND anzuschliessen klingt erstmal seltsam, laut Datenblatt ist das bei dem Typ aber auch gar nicht vorgesehen. Da steht nur "NC". Der NX3225GA hat auch so ein 4-Pin Glas-Gehäuse ohne Metall-Deckel und da steht im Datenblatt: "#2 and #4 are not connected. It is better to connect with a GND. But NC is also possible." So im Gegensatz zu http://cdn-reichelt.de/documents/datenblatt/B400/MT.pdf mit Metall-Deckel. Meine bevorzugten Quarze sind gerade die hier: https://www.digikey.at/product-detail/de/ndk-america-inc/NX3225GB-16M-STD-CRA-2/644-1233-1-ND/4914476 Zusammen mit 12pF Kondensatoren. Wenn die irgendwann mal verfügbar werden steige ich auf die NX2016 um. Die benutze ich seit einiger Zeit zum Beispiel mit dem ATMega16M1, meistens in kleinen Stückzahlen von Hand bestückt, die Woche habe ich aber gerade auch 80 Stück vom Bestücker bekommen und in Betrieb genommen. Der 16M1 hat keinen "Full Swing Crystal Oscillator", nur den "Low Power Crystal Oscillator".
batman schrieb: > Daß ein AVR Speicher löscht, die auf eine Retention >20y ausgelegt sind, > ist für mich der Witz. Bisher wurde ja nichtmal überprüft, ob der Flash sich alleine löscht (unwarscheinlich) oder der Bootloader versehentlich aufgerufen wird. Daß Leute wenig Sorgfalt in die Programmierung des Bootloaders legen, ist schon häufig vorgekommen. Ein Bootloader sollte immer auch Plausibilitätstests beinhalten.
Peter D. schrieb: > Ein Bootloader sollte immer auch Plausibilitätstests beinhalten. Oder den Code, der den eigentlichen Schreibvorgang durchführt, erst beim Flashen nachladen. So macht man das bei sicherheitskritischen Anwendungen. Da wird ein Flashdriver ins RAM geladen, und der übernimmt dann.
soul e. schrieb: > Da wird ein Flashdriver ins RAM geladen, und der übernimmt dann. Wo hast Du den ATmega328 her, der Programme im RAM ausführen kann?
Um zu testen, ob der Fehler aus den Bootloader Flashroutinen kommt, könnte der aktuelle Bootloader durch einen Dummy Bootloader ersetzt werden, der ausser dem Start der Applikation nichts weiter tut. Gruß, Stefan
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.