Errata - der Projektkiller

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

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?

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.

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.