Nabend. Ich lese mir grad die Errata vom xmega E durch. Da sind ja einige ärgerliche bei. Nun handelt es sich hier ja nicht um Software-Bugs, die man mal eben so fixen kann. Ich frage mich, ob Microchip beim Nachproduzieren theoretisch die Bugs fixen kann, oder ob das ein ganz anderer Prozess ist, den man einfach nicht macht, weil er ein Vermögen kostet. Letztendlich frage ich mich, wie hoch die Wahrscheinlichkeit ist, dass die irgendwann gefixed werden. Mir fehlen da einfach Erfahrungswerte.
Wenn der Druck von wichtigen Kunden mit hohen Stückzahlen da ist, wird gefixt. Leider weiß man als Aussenstehender nicht, ob das bei dem jeweiligen uC der Fall ist. Speziell bei den XMega würde ich vermuten, dass da wegen zu geringer Nachfrage nichts mehr gefixt wird.
Angehängte Dateien:
-
Errata.jpg
210 KB
Jan schrieb: > Letztendlich frage ich mich, wie hoch die Wahrscheinlichkeit ist, dass > die irgendwann gefixed werden. Mir fehlen da einfach Erfahrungswerte. Naja,es gibt ja dann in spaeteren Produktionen neuere Revisionen in denen dann Fehler behoben wurden. Im Anhang ein Auszug von einer Errata eines Pic12f1840 Bei dem gibt es offensichtlich eine Revision A4 und A5. Wobei A4 die aeltere Version ist und einen Siliconfehler enthaelt was durch ein "X" gekennzeichnet ist. So sehe ich das zumindest. A5 sollte also die erste Wahl sein wenn man ausgerechnet mit der fehlerbehafteten Hardwareeinheit zu arbeiten hat.Ansonsten kann man auch die aeltere Version einsetzen. Fuer manche Siliconfehler gibt es Software "work arounds" was ja dann aber auch in der Errata angegeben wird.
Häufig kommt es drauf an wie schwerwiegend die Fehler sind. Wir haben zum Beispiel einen Controller von NXP evaluiert und festgestellt, das eine Bussystem gar nicht darauf läuft, Errata hat es noch mal bestätigt, in der nächsten Maskenrevision war das Problem nicht mehr vorhanden.
Beitrag #6921381 wurde von einem Moderator gelöscht.
René F. schrieb: > in der nächsten Maskenrevision Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht automatisch eine Gelegenheit für ein Bugfixing ist. Na dann wird der xmega E wohl nicht mehr angefasst. Schade.
> Leider weiß man als Aussenstehender nicht, ob das bei dem > jeweiligen uC der Fall ist. Bei ST steht die Revision auf dem Chip. Vom STM32F407 gibt es z.B. eine 'A' und eine 'Z'. 'Z' steht wohl fuer: Hier ist Ende Gelaende.
Jan schrieb: > Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht > automatisch eine Gelegenheit für ein Bugfixing ist. Wie stellst du dir das vor. Dann wären unter der gleichen Revision korrigierte und unkorrigierte Versionen auf dem Markt. Ziel der unterschiedlichen Revisionsnummern ist doch gerade, dazwischen unterscheiden zu können.
Wie aus gut unterrichteten Kreisen verlautbarte, gibt es noch eine Revision '0'. Die ist aber nicht verfuegbar bzw. wird zu einem Produktpreis von $ 9.999.999,99 angeboten. Har har haar....
Cartman schrieb: > Vom STM32F407 gibt es z.B. eine 'A' und eine 'Z'. > 'Z' steht wohl fuer: Hier ist Ende Gelaende. Nicht unbedingt. Ich hab jetzt den konkreten STM Typ nicht im Kopf (ich glaube ein L0er), aber ich hatte schon eine Errata mit Z und nachfolgender Y Revision gesehen. Aber ich denke auch: ursprünglich sollte bei Z Ende sein und ist es wahrscheinlich auch bei 99% der Typen.
Sei froh dass die Errata überhaupt publiziert werden. Es gibt da einige Kandidaten, denen man den Fehler erst sehr detailliert nachweisen muss, während der Support erst meint das könnte ja alles nicht sein, um dann, wenn die Beweise erdrückend werden, ein fünf Jahre altes Dokument aus dem Hut zu ziehen, in dem alles genau beschrieben ist. Da gehört auch diese in Bastlerkreisen beliebte Bude dazu. Vorbildlich sind die Japaner. NEC, Mitsubishi, Renesas.
Wir hatten mal den Fall in der Firma mit einer ARM CPU von Atmel, wo es einen schwerwiegenden Fehler in der Grafikengine gab. Die GraKa war quasi fast nutzlos. Auf der embedded world sind wir dann auf einen engagierten Atmel-Mitarbeiter gestoßen, der uns folgendes berichtete: Man könne den Fehler nicht fixen, da der Fehler in einem zugekauften IP Core läge und die Lizenzrechte eine solche Korrektur nicht so einfach ermöglichen würden. Angeblich könne nur der Lizenzinhaber das durchführen, was zu einem neuen Lizenzvertrag führen würde. Genau da lag das Problem, dieses Szenario sei rein wirtschaftlich bei der CPU nicht mehr gegeben. Das war also ein Fall, wo errata nicht gefixt wurde. Es gibt aber zahllose andere Beispiele von Atmel und auch anderen Herstellern, wo Fehler recht schnell beseitigt wurden.
kommt vermutlich auch auf die Stückzahl an, wenn du 6-7 stellige Mengen brauchst, dann werden die Silicon Vendors schon Wege finden die Probleme zu beheben.
Beitrag #6921659 wurde von einem Moderator gelöscht.
Ich hab mal eine SW-Entwicklung mit einem 16Bit Renesas uC gemacht. Das Errata Sheet war ultra kurz, ich weiß gar nicht mehr, ob die 1 oder 2 Fehler den Chip betrafen, oder die zugehörige Flash-SW-Bibliothek. Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein kann- sind die Japaner so viel besser als die westlichen Chip-Entwickler? Ich kenne die entsprechenden Konkurrenzprodukte (MSP430/HCS08/HCS12) mit ihren teils dutzenden Seiten langen E.S. und das bei deutlich weniger komplexen Periperiemodulen im Vergleich zum Renesas uC.
APW schrieb: > Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein > kann- sind die Japaner so viel besser als die westlichen > Chip-Entwickler? Natürlich nicht. Das heißt nur, dass entweder der Chip kaum genutzt wird und deshalb noch keine Fehler aufgefallen sind, oder dass sie nicht-schwerwiegende Fehler einfach gar nicht veröffentlichen.
APW schrieb: > Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein > kann- sind die Japaner so viel besser als die westlichen > Chip-Entwickler? Das Problem dort ist: ab einer bestimmten Anzahl von Errata müssen sich die Chefs vor versammelter Weltpresse öffentlich und tränenreich entschuldigen. Bei noch mehr Fehlern ist das einmalige Aufsuchen des Büros mit dem Firmenschwert obligatorisch.
Ich hatte schon ein Errata gelesen wo bei jedem einzelnen Fehler explizit dabei stand das er nicht gefixt werden wird. So eine eindeutige Ansage habe ich aber bisher nur einmal gesehen.
Jan schrieb: > Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht > automatisch eine Gelegenheit für ein Bugfixing ist. Könnte daran liegen das es ohne Maskenrevision kein Bugfixing gibt.
>> sind die Japaner so viel besser als die westlichen >> Chip-Entwickler? > Natürlich nicht. Das heißt nur, dass entweder der Chip kaum genutzt wird Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr Stückzahlen als ST. Eben nicht im europäischen Raum, im asiatischen Raum schon. Das sieht man schon an den Foren. Eines in japanisch, eines in chinesisch und ein englisches für den Rest der Welt das aber im Vergleich zu den beiden anderen Sprachen kaum Einträge hat.
Janvi schrieb: > Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr > Stückzahlen als ST. Renesas ist mit seinen RH850 Controllern stark im Automotive Bereich vertreten, auch bei den deutschen Zulieferern.
Janvi schrieb: > Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr > Stückzahlen als ST. Weltweit hat Renesas ungefähr 50% mehr Marktanteil als STM. Nur NXP-Freescale-Motorola ist größer.
Haben mal ein schwerwiegendes Problem in einer Funktion entdeckt und über eine Instanz dazwischen (welche das Problem reproduzieren konnte dem Hersteller gemeldet. Nach langem Hin-Her und direktem Kontakt mit einem Repräsentanten des Chip-Herstellers wurde das Problem seitens Herstellers folgendermaßen gelöst: Die spezielle Funktion wurde einfach aus dem Feature-Sheet/Datenblatt/etc... gestrichen. Wäre wohl mit einem Firmwareupgrade zu beheben gewesen aber hat wohl außer uns keiner oder nicht viel verwendet. Errata dazu gabs meines Wissens nach nie. Wir verwenden einen dreckigen Workaround um die Funktion dennoch nutzen zu können.
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.