Hi Leute, ich bin gerade extrem frustriert, da ich fast fertig bin mit meinem Layout und nun feststellen musste, dass ein Silicon Errata mich wieder zurück auf Start wirft. Das Bauteil wird schön bei jedem Distri, auf der Homepage und im Datenblatt beworben, dass es Energy Efficient Ethernet supportet. Pustekuchen! Im Errata steht, dass es dann zu sporadischen Linkabbrüchen führen kann. Der Workaround: EEE deaktivieren. Was ist das für ein BULLSHIT. Das ist Kundenverarsche. Ich kaufe mir doch auch kein Auto, welches mit Rückfahrkamera beworben wird um dann im Handbuch zu lesen, dass man die deaktivieren muss um überhaupt rückwärts fahren zu können. Dann könnte ich mich immerhin an irgendwelche Verbraucherzentralen wenden, aber hier bleibt man der Dumme. Und bei einem anderen Projekt und Bauteil fielen bei Klimatests Abweichungen zum Datenblatt auf, bei Nachfrage beim Hersteller gab es plötzlich ein neues Datenblatt mit doppelt so schlechten Toleranzen. Ein Glück konnte ich die Schaltung in der nächsten Revision ändern, sodass ich nicht davon abhängig war. Ist euch das auch schon mal passiert? PS: ja ich habe das Errata vorher gelesen, aber scheinbar nicht genau genug.
:
Verschoben durch Moderator
jo, bin bei den ATXMega 192A1 damals darüber gestolpert, das man das interne EEPROM nur schreiben sollte, wenn der MC im Sleep Modus ist. Das ist für eine Motorsteuerung aber ganz schlecht. Der Workaround war dann ein externes 93C46 mit SPI Bitbanging. Schönen Dank, Atmel.
Tja, das passiert halt wenn man immer den neuesten Scheiß haben will anstatt auf altbewährtes zu setzen ....................
Ben B. schrieb: > Tja, das passiert halt wenn man immer den neuesten Scheiß haben will > anstatt auf altbewährtes zu setzen .................... Eben, ich nutze für alles grundsätzlich einen 8051, also auch für Ethernet, Wifi, Bluetooth, GPS, Zigbee, 3MB Flash, 1MB Ram und den krassesten Schei**, den die alle direkt im Chip haben und auch adressieren können, bei 200MHz Takt. @errata hatte ich bisher keine Probleme, aber wohlgemerkt ich hatte vermutlich nur Glück
D.C. unangemeldet schrieb: > ich bin gerade extrem frustriert, da ich fast fertig bin mit meinem > Layout und nun feststellen musste, dass ein Silicon Errata mich wieder > zurück auf Start wirft. ... > Im Errata steht, dass es dann zu sporadischen Linkabbrüchen > führen kann. Der Workaround: EEE deaktivieren. > Was ist das für ein BULLSHIT. Wie wär es mal mit Ingenieurgehirn einschalten und sich eine passende Fehlerbehandlungsprozedure wie timerbasierte Linkkontrolle und ggf neuaufbau der Kommunikation einfallen lassen?! Es ist auch nicht ersichtlich, warum das Dich beim layout zurückwirft, für ein fehlertolerantes Design muss man bei jedem Controller Selbstüberwachung und ggf. neustart einplanen. Aber wie heisst es so schön: "Ein schwarzes Schaf, zur rechten Zeit, erspart den Streit, bringt Einigkeit"
Ich hab mir mal von einem MC 2 Eval-Sample aufschwatzen lassen. Ich hab ihn natürlich nicht eingesetzt. Er wurde dann auch wieder eingestampft, d.h. nie richtig produziert. Das wäre also ein sehr teurer Spaß geworden. Für reale Projekte nehme ich nur ICs, die mindestens 1 Jahr lang in Produktionsstückzahlen von 2 Distris verfügbar sind.
Ben B. schrieb: > Tja, das passiert halt wenn man immer den neuesten Scheiß haben will > anstatt auf altbewährtes zu setzen .................... Altbewährt = kurz vor der Abkündigung + alte Technologie Leider dreht sich die Welt weiter und es kommen ständig neue Chips raus die man verwenden muss für ein modernes Produkt.
Fpgakuechle K. schrieb: > Wie wär es mal mit Ingenieurgehirn einschalten und sich eine passende > Fehlerbehandlungsprozedure wie timerbasierte Linkkontrolle und ggf > neuaufbau der Kommunikation einfallen lassen?! Und wie implementiert mir das nun den 802.3az Standard auf Physical Layer Ebene?
Ben B. schrieb: > das passiert halt wenn man immer den neuesten Scheiß haben will > anstatt auf altbewährtes zu setzen Es passiert dann, wenn man die Errata nicht liest. 1) Features lesen: Ist das Ding für das geeignet, was ich machen will. 2) Errata lesen: Die zählen in gewissem Sinne ja auch zu den "Features". Kann das Ding wirklich das, was groß und breit angepriesen wird? Es gibt Microcontroller wie manche Infineon TriCore, deren Errata Sheet länger ist als das Manual anderer Controller wie etwa Atmel AVR. Und die AVR-Manuals sind ausführlich... Ja, ist ärgerlich, aber gehört eben dazu. Nicht nur für Hard- und Firmware- Entwickler, auch für Compiler-, Debugger- und Simulator-Hersteller. Und wenn man dem Hersteller ein unbekanntes / nicht veröffentliches Erratum reportiert, dann wird das gerne mal als "Feature Update" behandelt (Errata angepasst) anstatt dass der Bug in der nächsten Revision behoben wird.
Fpgakuechle K. schrieb: > Wie wär es mal mit Ingenieurgehirn einschalten und sich eine passende > Fehlerbehandlungsprozedure wie timerbasierte Linkkontrolle und ggf > neuaufbau der Kommunikation einfallen lassen?! Eine Fehlerbehandlung soll die Zuverlässigkeit erhöhen, d.h. sie darf nur sehr selten triggern. Sie ist aber untauglich, wenn sie als Würg-Around für eine grottige Hardware herhalten muß. Im günstigsten Fall hat der MC dann ständig Schluckauf, d.h. setzt aus, bis der Timeout zuschlägt. Ein definiertes Zeitverhalten läßt sich so auf keine Fall mehr erreichen.
> Es passiert dann, wenn man die Errata nicht liest. Bullshit. Ich glaube jeder Entwickler liest das Errata bevor er auch nur eine LED in seiner Schaltung verwendet. Die Probleme entstehen, wenn Hardwarefehler zum Zeitpunkt der Produktentwicklung noch nicht bekannt sind und erst nach dem Hardwaredesign entdeckt werden. Das sorgt dann für lange Gesichter, weil der Wechsel auf einen anderen Controller teuer und zeitraubend ist. Wieso ich schreibe der neueste Scheiß ist scheiße? Eigene Erfahrung, mit einem HIP4081. Das Ding kann auf den ersten Blick wirklich alles, was man für die Steuerung einer MOSFET-Vollbrücke braucht. Highside-Ladungspumpe, Shoot-Through-Schutz... toll. Auf den zweiten Blick war das Scheißteil trotz sorgfältiger Einhaltung der Design Rules nicht stabil zum Laufen zu bekommen, insbesondere der Shoot-Through-Schutz erwies sich eher als Shoot-Through-Generator. Der IC erzeugte Fehlansteuerungen wo immer es nur ging und nahm sich mit der Betriebsspannung der FETs selbst das Leben. Dem steuernden AVR fehlten danach ein oder zwei Port-Pins bzw. wenn man diese (ich glaube) nach low schalten wollte, hatte man eine schicke On-Chip-Heizung, aber keinen low-Pegel mehr. Auch eine tolle Sache, stand so aber nicht im Lastenheft. Nach etlichen Tagen verschwendeter Zeit eine Adapterplatine mit zwei IR2113-Arbeitstieren und einer Ladungspumpe mit dem ebenfalls sehr zuverlässigen NE555 zurechtgezimmert, um wenigstens mit dem Rest des Projekts weitermachen zu können - mit dieser absoluten Pfusch-Lösung ist die Schaltung im ersten Anlauf problemlos und zuverlässig gelaufen. Also wozu bitte soll ich da neue Schaltkreise verwenden, wenn ich mit dem altbewährten Arbeitstier absolut keine Probleme habe?
:
Bearbeitet durch User
Selbst wenn man die Errata liest kann es passieren, dass ein Chip eben doch nicht das tut, was er soll. Wenn der Chip dann nur 3€ kostet und man auch nur 1000 pro Jahr braucht, dazu noch dieses IC aus einem Zukauf ins Portfolio des Herstellers gelangt ist dann, ja dann, kann es auch passieren, dass man einfach abtropft. Besonders ärgerlich ist das, da es sich natürlich um ein Nischenprodukt handelt, was nicht jeder Hersteller im Programm hat, man also auch kaum Alternativen findet, Pinkompatible sowieso schon gleich gar nicht. Damit muss man leben. Sowas passiert einmal aller 3 Jahre im Schnitt. Allerdings ist dann natürlich die Kacke ziemlich am dampfen. Wenn man dann eine cholerische Ader (oder einen Chef mit selbiger) aufweist wird es ne harte Zeit. Besonders problematisch ist das, wenn etwas bei den ersten Mustern und der Vorserie problemlos funktioniert. Man dann aber in der Serie, am besten nach ca. 3 Monaten Betrieb im Feld, plötzlich massive Ausfälle auftreten. Wir hatten einen Fall der im Gedächtnis bleiben wird: Einen FPGA im System. Am Config Done Signal war eine LED angeschlossen (mit Vorwiderstand natürlich). Die war für die Programmentwicklung des FPGA wichtig. Natürlich hat sie es auch in die Serie geschafft. Plötzlich, im Herbst, als die Temperaturen geringer wurden sind die Geräte bei der Inbetriebnahme mit geöffnetem Fenster reihenweise ausgefallen. Nachdem dort die LED durch einen 10k Widerstand ersetzt wurde lief das Teil. Die Fehlersuche zog sich auch über Wochen hin, weil man auf so etwas nicht kommt. Zuerst sucht man in der Spannungsversorgung, dann lässt man Platinen röntgen um etwaige Lötfehler zu finden. (Insbesondere das Thermische Verhalten, bei warmer Baugruppe funktioniert sie, bei kalter nicht deutet doch sehr auf so etwas hin) Klar fragt man auch beim Hersteller des FPGA an, allerdings dauert das gern mal bis sich jemand findet, der sich dem Problem annimmt, insbesondere bei marginalen Stückzahlen. Wenn dann die Produktion der Cash Cow dran hängt ist natürlich mit steigendem Druck aus allen Ebenen, bis hin zum letzten Schrauber in der Fertigung, der seinen Lohn am Monatsende in Gefahr sieht, zu rechnen. Irgendwann wird dann jeder Gang außerhalb des Büros zu einem Spießrutenlauf. Wer da nicht die Ruhe bewahren kann hat verloren.
D. C. schrieb: > Altbewährt = kurz vor der Abkündigung + alte Technologie Es werden auch neue Chips oft wieder abgekündigt. Z.B. die Luminary ARM mit internem PHY hatten mir sehr gut gefallen.
Manche Chips schaffen es auch nicht weiter als bis zum Engineering Sample, Beispiel wäre der SAM3X8H, der wäre damals von den technischen Daten für eine Applikation von uns perfekt gewesen.
D.C. unangemeldet schrieb: ... > Ist euch das auch schon mal passiert? ... Das passiert leider regelmäßig, auch wenn man im Vorfeld alle verfügbare Doku liest. Das kostet leider oft einiges Geld und vor allem Projektzeit. Die positive Auswirkung ist, hat man sich seine "eigenen" Einträge in den Erratas erarbeitet, dass manchmal Jahre später noch sich die Mitarbeiter der Chiphersteller an einen erinnern (teilweise bis in die Entwicklungsabteilungen). Die Hersteller unterscheiden sich leider in der Handhabe solcher Themen. Im Nachhinein besonders gute Erinnerungen habe ich an TI, ADI, Micrel. Atmel, als eigenständige Firma, war stark vom Baustein abhängig. Was Microchip und ST angeht, so ziehe ich es vor hier nichts schreiben.
Deshalb auf Open Hardware setzen! Da kann man es weiter produzieren lassen und die Bugs selbst fixen.
Neben Errata gibts ja auch noch unvollständige Dokumentation. Das kann einen genausoviel Zeit kosten. Kann mich da noch dunkel an einen Smartcard-Interface-Chip von NXP erinnern (TDA8034 oder so). Das dumme Ding hat eigentlich nur harmlose Funktionen wie Pegelwandler, Treiber/Überstromschutz, Reset-Kram und sowas. Die Ansteuerung der paar IOs kam von einem anderswo gut laufenden Treiber von Intel und sah völlig sinnvoll aus. Und trotzdem wurde der Chip beim ersten Aktivieren der SC knallheiss bis zum Abschalten. Nach diversen Eskalationstufen und einen Monat später (Abwimmeln ala blöder Kunde hat den Chip falsch eingelötet, durch ESD ruiniert, kaputte Schaltung, Powersupply falsch ...) hat ein NXP-Ingenieur lapidar mitgeteilt, dass der Chip die "normalen" IOs, die ja eigentlich nur an die SC weitergereicht werden, in einer bestimmten (für SCs "ungültigen" Kombination) als Übergang in einen undokumentieren Testmodus ansieht. Und der macht dann Querströme in der normalen Beschaltung. Die zeitliche Vertauschung zweier Signale im Treiber hat das Problem gefixt. Argl.
Christian B. schrieb: > Selbst wenn man die Errata liest kann es passieren, dass ein Chip eben > doch nicht das tut, was er soll. Errata sind mitunter so formuliert, dass man erst hinterher merkt, dass man es hätte vorher wissen können. Man will die Kundschaft ja nicht verprellen, also wählt man eine Ausdrucksweise, die das Problem herunter spielt, oder als exotisches Szenario erscheinen lässt.
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.