atari-home.de - Foren
Hardware => Firebee => Thema gestartet von: Mathias am Di 26.07.2016, 22:50:51
-
Auf http://firebee.org wurde soeben ein detailierter Artikel zu den Vorgängen um die Lieferverzögerung der neuen FireBee-Serie veröffentlicht.
Beileidsbekundungen werden hier, in den Kommentaren auf firebee.org oder per Mail entgegengenommen!
-
Liest sich fast wie das Script eines Horrorfilmes. Im Grunde konnte ja gar nicht viel mehr schief gehen. :'( Richtig übel sind die nicht funktionierenden Boards. Ich hoffe, dass sich das halbwegs klären lässt und alle aus der Sache heil rauskommen. Das ist noch mit das Wichtigste, denke ich: Die Hardware sollte 100 %-ig funktionieren, auch wenn sich die Lieferung dann um ein halbes Jahr verzögert. Dann liegt die Biene eben unterm Weihnachtsbaum. Das stellt auch kein Problem dar für mich. :)
Und ich glaube der alte Gehäusebauer hatte keinen Bedarf mehr an dem Auftrag. Deswegen hat er den Preis entsprechend nach oben getrieben. Wenn die neuen Gehäuse genauso gut werden sollte es den Endkunden nicht weiter stören. ;D
-
Hach, so verständnisvolle Kundschaft wie Dich, kann man sich nur wünschen! ;)
Das mit den Board ist extrem mühsam und macht auch enormen Druck logischerweise. Mittlerweile – während wir übersetzt haben – gibts auch eine erste Ahnung, daß es sich um einen defekten Bauteil handelt. Aber das ist noch nicht 100% klar. Genaueres sobald sich die Nebel lichten.
Das mit dem Gehäusebauer finde ich persönlich extrem schade. Ist ja "mein Baby" das Gehäuse. Wir hatten noch eine 1 1/2 Stündiges persönliches Gespräch vor Ort, alles war gut, und dann bestellen wir noch einen Haufen Gehäuse mehr, und auf einmal ist der Preis viel höher. Das wäre sogar "illegal" gewesen, da wir ja das Anbot ohne Zeitrahmen hatten für Februar/März, aber darauf zu pochen hätte keinen Sinn gemacht. Meine persönliche EInschätzung ist, daß der Juniorchef, der jetzt mehr macht dort, einfach mal versucht hat "ob´s reingeht".
Aber ich lass mich nicht gerne verarschen.
Etwas positives hat die Sache mit dem neuen Gehäusehersteller aber dennoch, wir können sie jetzt direkt zu MCS exportieren lassen, da alles – also Logofräsung, Verkitten, Lackiern, Siebdrucken – aus einer Hand kommt. Das macht mir das Leben um einiges leichter, und ich muß mich nur noch um Verpackung, "Handbuch" und Co. selber kümmern.
Dein Gehäuse ist übrigens von der 2. Serie und zurückgelegt. ;)
-
Etwas positives hat die Sache mit dem neuen Gehäusehersteller aber dennoch, wir können sie jetzt direkt zu MCS exportieren lassen, da alles – also Logofräsung, Verkitten, Lackiern, Siebdrucken – aus einer Hand kommt. Das macht mir das Leben um einiges leichter, und ich muß mich nur noch um Verpackung, "Handbuch" und Co. selber kümmern.
Manchmal haben solche auf den ersten Blick negative Ereignisse, ein positives Ende oder Weiterentwicklung. Aber ich fürchte, ihr hatte in letzter eine ganze Menge Stress und habt auch gekotzt ohne Ende. Insofern drücke ich euch auch die Daumen, dass ihr den Fehler auf den Boards findet und der sich beheben lässt. Wenn's ein defektes Bauteil ist, dann muss sich dessen Hersteller wohl dafür verantworten, denke ich. Aber das ist auch alles so 'ne Sache. Genügend Erfahrungen habe ich auch dahingehend schon gemacht.
Hach, so verständnisvolle Kundschaft wie Dich, kann man sich nur wünschen! ;)
Liegt auch daran, dass ich zur Zeit nicht so die Zeit hätte mich mit der Biene zu beschäftigen. Wenn sie dann gegen Jahresende kommt, sieht's besser aus. ;)
Dein Gehäuse ist übrigens von der 2. Serie und zurückgelegt. ;)
Du meinst der 1. Serie? ;D Das wäre dann insofern wohl eine einmalige Konstruktion, weil ein Board der 2. Serie in einem Gehäuse der 1. Serie ausgeliefert würde. Praktisch die rosa Mauritius unter den Firebees! 8)
-
Neinnein, ich meine schon die 2. Gehäuseserie. Wir haben ja für die 1. Boardserie 2 mal Gehäuse produzieren lassen, da sie besser angekommen sind als gedacht.
-
Ah. Ok. Jetzt habe ich das verstanden. Aber 2. Gehäuseserie und Board der 2. Serie sollte auch etwas eher seltenes darstellen. ;D
-
Habt Ihr Murphy so verärgert? ;)
Die Transparenz finde ich klasse, das wird schon!
VG
Sven
-
Anscheinend ;-)
Danke auch für die aufmunternden Worte. Ich bin auch sicher das das wird. Nur sind die mehrfachen Verzögerungen halt blöd. Und ad Transparenz, klar; das ist das Schöne an so einem nichtkommerziellen Projekt. Ich muß nichts verkaufen, keine "Gschichtln drucken" und mit Marketingsprech das Blaue vom Himmel usw., ... Das ist schon sehr angenehm! Ich denke auch daß man mit der Wahrheit immer am Weitesten kommt. Die bisherigen Reaktionen bestätigen das wiedereinmal.
Aber wisst ihr was ich schon auch enorm froh bin: daß das mit den Boards jetzt bei der 2. Serie passiert, wo doch die 1. bauchgleich ist und läuft. Wäre das bei der Produktion von der 1. damals so abgelaufen, dann wären die Vaporware-Gerüchte aufgekommen. ;)
-
Gleich Gehäuse mit Platz für Grafikkarte :D
-
Gleich Gehäuse mit Platz für Grafikkarte :D
Erstmal PIC-Code, dann Forderungen stellen. :-p
Und nein, ich werde die Gehäuse nicht umdesignen, nachdem ich den Leuten Mini-Cases verkauft habe! Und wenn Du´s ernst meinst, dann schau Dich mal im Entwicklerforum um, und tu hier nicht blöd reden. ;) Und außerdem Gehäuse mit Grafikkarten zu verkaufen solange die Grafikkarten nicht immer gehen ist auch ein bissl witzlos, oder?
-
Hey ich mag Grafikkarten :-P
-
Hey ich mag Grafikkarten :-P
OK, dann machen wirs so: Deine FireBee wird im 3HE 19" Rack geliefert. Drinnen ist eine Backlplane mit 19 Steckplätzen, eine FireBee und 18 Radeon 9200-Grafikkarten. Aufpreis ist 999,- zum Minigehäuse. Und ob die Karten gehen ist ja eh wurscht.Passt das? :-p
-
Du hast doch ein Setup mit Radeon am laufen, was hältst Du davon wenn ich ein Video davon mache? Ich habe den anderen auf der HomeCon versprochen die Kombi zu testen. ;)
-
Du hast doch ein Setup mit Radeon am laufen,
Wie oft noch, nein habe ich nicht! Das läuft nicht stabil. Erst bei jedem 30. Booten oder so gehts zufällig. Das ist keine Option für irgendwas so wie der derzeitige Stand ist.
Und wenns dann mal läuft machen ein Haufen MiNT-Programme Probleme, …
-
Drinnen ist eine Backlplane mit 19 Steckplätzen, eine FireBee und 18 Radeon 9200-Grafikkarten.
Bei der Anzahl der verbauten Grafikkarten erhöht das aber die Chancen, dass eine funktionieren könnte. ;D
Liegt der Fehler an der Grafikkarte selbst? Habt ihr mal unterschiedliche getestet? Die Backplane? Wobei diesbezüglich die Auswahl geringer ausfallen könnte als bei der Grafikkarte oder ist's schlichtweg der Treiber, der spinnt?
Ich habe den anderen auf der HomeCon versprochen die Kombi zu testen. ;)
@Mathias gib doch einfach @Börr die besagte Kombi und der macht und dann läuft alles wie bekloppt! :P
-
Bei der Anzahl der verbauten Grafikkarten erhöht das aber die Chancen, dass eine funktionieren könnte. ;D
Genau! :-p
Liegt der Fehler an der Grafikkarte selbst? Habt ihr mal unterschiedliche getestet? Die Backplane? Wobei diesbezüglich die Auswahl geringer ausfallen könnte als bei der Grafikkarte oder ist's schlichtweg der Treiber, der spinnt?
Der Fehler liegt nach meinen spärlichen Informationen einzig an einem gangbaren Weg zur Stromversorgung vom PCI-Bus. Ich hab aber 0 Plan von Elektronik.
Ich habe den anderen auf der HomeCon versprochen die Kombi zu testen. ;)
Mathias gib doch einfach Börr die besagte Kombi und der macht und dann läuft alles wie bekloppt! :P
Der soll mal den PS/2 code für den PIC schreiben. ;) Und nein, nachdem er derzeit nur eine Entwicklerbiene hat, lieber keine PCI-Tests, sonst brutzelt die Biene. Wenn seine eigene da ist, dann von mir aus. :-)
-
Ich hoffe das alles wie erhofft klappt und drücke euch die Daumen.
-
Auf http://firebee.org wurde soeben ein detailierter Artikel zu den Vorgängen um die Lieferverzögerung der neuen FireBee-Serie veröffentlicht.
Die Seite hat einen Fehler:
Ganz oben:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=UTF-8"/>
Der letzte / fehlt, sonst zeigt opera die Umlaute nicht richtig.
-Helmut
-
Oh, danke Helmut, wird weitergeleitet an den Webmaster.
-
Der soll mal den PS/2 code für den PIC schreiben. ;) Und nein, nachdem er derzeit nur eine Entwicklerbiene hat, lieber keine PCI-Tests, sonst brutzelt die Biene. Wenn seine eigene da ist, dann von mir aus. :-)
Ich hatte mal vor längerer Zeit ein PS/2-Keyboard an einem PIC angeschloßen. Die Implementierung war nicht ganz fertig, es fehlte noch der Parity-Check und der Befehl zum erneuten Senden des letzten Bytes bei Patrity-Fehler. Der Code war für C18 auf einem PIC18F46K20 geschrieben.
Bei Interesse ist es auf GitHub zu finden, als Teil meines DevelOS-Projektes (https://github.com/Stefanie80/DevelOS.X).
Die Dateien für den PS2-Treiber sind ps2-keyboard.c und .h
Aber ich denke bei mir lief der eigentliche Datenempfang im IRQ-Handler, den ich inzwischen mehrfach umgeschrieben habe. Der Code ist aber noch da, in der Datei newmain.c
Nur durch ein #define deaktiviert.
Für Fragen stehe ich gerne zur Verfügung, und wünsche euch weiterhin viel Erfolg bei dem Projekt
-
Hi SolderGirl!
Das Problem ist nicht der Code für PS/2 soweit ich das verstanden habe, sondern die Integration mit den weiteren Komponenten. Der PIC auf der FireBee ist ja für mehrere Dinge zuständig wie Du hier sehen kannst: http://firebee.org/fb-bin/page?label=Zoom_inside_the_PIC&lng=DE
Der GamePort und PS/2 sind derzeit nicht implementiert. Der Rest liegt in Assembler vor. Den Code für PS/2 selber gibt es ja schon in diverse Projekten auch als Open Source. Es haben schon ein paar Leute angefangen damit, aber irgendwie scheint es immer an der Integration mit den anderen schon laufenden Komponenten in Assembler zu scheitern, wenn ich die Entwickler richtig verstanden habe?
-
Ja, die Herausforderung dabei ist für mich Assembler. Es liegt auch eine Codebasis in C vor, aber die läuft nicht. Ich habe angefangen anhand des funktionieren Assembler Codes den C Code zu debuggen, aber da der PIC einige andere Chips initialiseren muss, hing es schon beim Booten des Systems........
-
Oh ja, das Problem kenne ich nur zu gut. Sobald man versucht, mehrere Funktionen in einem PIC unterzubringen, wird er extrem zickig. Vor allem muß man auf sehr kurze IRQ-Handler achten, die IRQ-Flags müssen genau richtig abgefragt werden, und selbst dann ist es noch nicht sicher das es läuft.
Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
-
Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
Nice, aber bestimmt in c?
-
Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
Nice, aber bestimmt in c?
Ja, komplett in MPLAB-X in C geschrieben
-
*träumt von hochsprachen*
Vielleicht hast du mal Lust mir bei rausfinden zu helfen, was das minimal Initzeug ist um von ASM auf C umzusteigen.
-
So, es gibt ein paar Neuigkeiten auf http://firebee.org
Problem schon mal eingegrenzt, vielleicht auch eine flotte Lösung, wenns wirklich daran liegt.
-
Das wird schon ;) Atarianer sind eine sehr geduldige Spezies ;) Was sind da schon einige Monate Verzug ;) Hauptsache alles wird gut und da bin ich sehr zuversichtlich.
-
Sehe ich auch so wie mein Vorredner.
-
Ich wollte eben mit meinem iPad mini (aktuelles iOS und Safari) einen Kommentar absetzten auf firebee.org. Das gab aber eine Fehlermeldung:
500 - Internal Server Error
Also poste ich den Kommentar mal hier:
Das sind doch im Grunde keine so schlechte Neuigkeiten. Macht euch keinen Stress damit, wenn's ein paar Wochen länger dauert, dann ist das auch so. Wenigstens die Boards funktionieren zuverlässig.
Was mich viel mehr interessierte wie man bei den Multilayerboards das zickige Bauteil ausgelötet bekommt und das neue wieder drauf. Das stelle ich mir verdammt schwierig vor und das klingt vor allem nach einer ganze Menge Arbeit für den Bestücker.
-
Was mich viel mehr interessierte wie man bei den Multilayerboards das zickige Bauteil ausgelötet bekommt und das neue wieder drauf. Das stelle ich mir verdammt schwierig vor und das klingt vor allem nach einer ganze Menge Arbeit für den Bestücker.
Das ist technisch jetzt nicht sooo kompliziert. Auf der FireBee sind ja sämtliche der fast 1000 Bauteile, bis auf die Header und Schnittstellen, als SMD ausgeführt. Die großen Chips als BGA. Da gibt es Maschinen mit denen man das professionell austauschen kann. Merkt man hinterher gar nicht. Das darf man sich nicht als händisches "rumbasteln" vorstellen. Die Bauteile werden vorgewärmt, sauber abgelötet und mit den Neuen ersetzt.
Z.B. mit einer Onyx: http://www.zevac.ch/de/rework_products/smt_systems/onyx_29.php
So ein Gerät kostet halt, ist aber der Job vom Bestücker ;)
Hier im Forum gibts ein paar Leute die da auch Erfahrung mit sowas haben, und sicher mehr erzählen könnten als ich.
-
Hier ist ein nettes Werbevideo wie das dann vonstatten geht: https://www.youtube.com/watch?v=UY2MFbk-bN0
-
Da gibt es Maschinen mit denen man das professionell austauschen kann. Merkt man hinterher gar nicht. Das darf man sich nicht als händisches "rumbasteln" vorstellen. Die Bauteile werden vorgewärmt, sauber abgelötet und mit den Neuen ersetzt.
Z.B. mit einer Onyx: http://www.zevac.ch/de/rework_products/smt_systems/onyx_29.php
So ein Gerät kostet halt, ist aber der Job vom Bestücker ;)
Hier im Forum gibts ein paar Leute die da auch Erfahrung mit sowas haben, und sicher mehr erzählen könnten als ich.
Gibt da mehrere möglichkeiten, mit einer Zevac habe ich auch schon gearbeitet.
Wer es genau wissen will, sollte mich auf einer Veranstaltung ansprechen, per Email wird mir das zu lang...
-
Ist schon interessant anzugucken. Ich bin echt überrascht, dass das alles so reibungslos funktioniert. Diese Automaten müssen doch letzten Ende im µm-Bereich arbeiten können. Ansonsten käme doch Murgs bei raus. Ich müsste eine solche Maschine wohl echt mal live sehen und mir gleichzeitig erklären lassen. So verstehe ich von ihr nur einen sehr kleinen Bruchteil.
-
So Supergenau muss man das gar nicht machen, die Bauteile "schwimmen" beim Löten ein.
Natürlich platziert man so genau wie möglich.
-
Die Hoffnungen, beim neuen Board eine Lösung gefunden zu haben, waren wohl trügerisch, wie mit Datum vom 30.09.2016 die firebee-Website mitteilt. Das Austauschen des Bustreibers brachte jedenfalls nicht die erhoffte Lösung des Problems. Derzeit soll das Thermal Pad des Bustreibers vom Board gelöst werden, um einen Lösungsansatz zu testen. Der andere Ansatz besteht darin, auf einem Board testweise einen identischen Bustreiber statt dem bisherigen aufzulöten, der allerdings mit internen Pullups ausgestattet ist.
Näheres auf der Website unter: http://firebee.org/fb-bin/news?lng=DE (http://firebee.org/fb-bin/news?lng=DE)
-
Pullups im Bustreiber waren es nicht. Ein Kapton-Band zwischen Thermal Pads und Platine bringts. ;)
Wir haben das erste voll funktionstüchtige Board stundenlang erfolgreich getestet. Die Auslieferung der Vorbestellungen dieser 2. Serie beginnt mit Ende Oktober. Puh - schwere Geburt!
Siehe: http://firebee.org/fb-bin/news?&lng=DE
-
Freut mich das der Fehler nun gefunden ist.
-
Ein Kapton-Band zwischen Thermal Pads und Platine bringts. ;)
Was ist denn das schon wieder?! :D
Aber ist echt interessant, dass das jetzt erstmal bei der zweiten Serie nicht wollte. Da muss es doch bei der ersten Serie eine bessere Isolierung gegeben haben?
Die Auslieferung der Vorbestellungen dieser 2. Serie beginnt mit Ende Oktober.
Mist. Ich wollte meine Firebee doch erst zu Weihnachten haben!
Puh - schwere Geburt!
Seht's mal so: Wieder etwas gelernt! Und letzten Endes hätte alles viel schlimmer kommen können. Seid ein wenig stolz auf euch, dass ihr den Fehler gefunden habt und ihr die Besteller glücklich machen könnt. 8)
-
Das ist irgendsoein Material das halt komplett isoliert, aber die Wärme dennoch abtransportiert.
Und wenn Du dein Board erst später haben willst, kein Problem, wir hebens gerne nochmal 4 Jahre auf ;) Eigentlich wollte ichs Dir ja als allererstem zukommen lassen, aber Dein Wunsch ist mir Befehl ;-p
Hmm, und was wir gelernt haben weiß ich noch nicht so genau. Für mich stellt sichs momentan so dar als ob man sich halt nicht auf Datenblätter und schonmal funktionierende Chips verlassen darf. Und daß man außerdem Halbleiterherstellern ausgeliefert ist, ... aber mal schaun es sind grade noch Leute dran die das alles tatsächlich behirnen ;)
-
Und wenn Du dein Board erst später haben willst, kein Problem, wir hebens gerne nochmal 4 Jahre auf ;) Eigentlich wollte ichs Dir ja als allererstem zukommen lassen, aber Dein Wunsch ist mir Befehl ;-p
Also vier Jahre müssen jetzt auch nicht sein. :o Das waren jetzt schon vier Jahre. ;D Mitte Dezember passt ganz gut. Dann sind ein paar freie Tage in Sicht und ich kann mit der Biene dann etwas spielen.
ür mich stellt sichs momentan so dar als ob man sich halt nicht auf Datenblätter und schonmal funktionierende Chips verlassen darf. Und daß man außerdem Halbleiterherstellern ausgeliefert ist, ... aber mal schaun es sind grade noch Leute dran die das alles tatsächlich behirnen ;)
Der Hersteller muss ja irgendwas an seinen Teilen geändert haben? Ansonsten sollte das ja funktionieren wie bei der ersten Serie? Vielleicht haben die auch eingespart, um mehr Gewinn zu machen und den Chip etwas dünner gemacht. Oder diejenigen, die die Teile gefertigt haben, haben das gemacht. Wenn man so will, habt ihr sowas wie den VW-Abgasskandal aufgedeckt. Ich sehe schon die Schlagzeile auf heise online:
Datenblätter falsch! Fertiger spart Material, weil er seine Chips 0,5 mm dünner machen wollte ...
Wenn ihr man jetzt nicht noch die ganz große Chipskandalkuh ausgegraben habt! Könnte aber das ACP und auch die Firebee ins Rampenlicht rücken, weil alle namhaften Computermagazine der Welt darüber berichten werden.
:D ;D 8) :o
-
Hmm, und was wir gelernt haben weiß ich noch nicht so genau. Für mich stellt sichs momentan so dar als ob man sich halt nicht auf Datenblätter und schonmal funktionierende Chips verlassen darf. Und daß man außerdem Halbleiterherstellern ausgeliefert ist, ... aber mal schaun es sind grade noch Leute dran die das alles tatsächlich behirnen ;)
Man sollte immer genau prüfen ob man tatsächlich genau den gleichen Chip geliefert bekommt.
Jeder Suffix in der Nummer ist wichtig.
Allerdings kann man sich darauf auch nicht 100% verlassen.
Regelmässig nach aktualisierten Datenblätter schauen ist leider ein notwendiges Übel geworden.
Selbst wenn man so viele Chips verbaut das einen der Hersteller direkt beliefert wird kann es passieren das Spezifikationsänderungen mal nicht mitgeteilt werden.
Wer über Distris kauft braucht auch große Stückzahlen damit man informiert wird.
Ziemlich ärgerlich weil sowas immer irrsinnige Kosten verursacht. Das wechseln des Chips, anbringen der Isolierung, evtl. reballing oder neuen Chip verwenden dauert länger als das Board zu bestücken und die Kosten bekommt man von den Chipherstellern nicht ersetzt...
-
Man sollte immer (…)
Ja, damit hast Du natürlich recht. Jedoch ist das ja nicht der Punkt bei uns. Fredi Aschwanden ist ja kein Anfänger. ;)
Abgesehen davon besorgt ja unser Bestücker die Bauteile nach Stücklisten, was viel günstigere Konditionen ermöglicht, als wir mit unseren 3-stelligen Anzahlen. Deshalb haben die sich auch sehr bemüht jetzt (insgesamt 4 Boards umgebaut), obwohl sie anscheinend keinerlei Schuld trifft.
Also soweit ich das bis jetzt durchblicke beginnen die Teile einfach nachdem sie warm werden übers Thermal Pad zu leiten. Und sowohl im aktuellen Datenblatt als auch per schriftlicher Aussage von TI im Zuge der Fehlersuche ist das Thermal Pad intern mit Nichts verbunden angeblich. Und es hat ja bei den Prototypen und der ersten Serie eben auch problemlos funktioniert, ... Aber mal schaun, was die Hardwarejungs dann im Endeffekt rausfinden.
Ziemlich ärgerlich weil sowas immer irrsinnige Kosten verursacht. Das wechseln des Chips, anbringen der Isolierung, evtl. reballing oder neuen Chip verwenden dauert länger als das Board zu bestücken und die Kosten bekommt man von den Chipherstellern nicht ersetzt...
Ja, das ist auch noch ungeklärt. Ich hoffe daß das nicht noch unlustig für MCS wird, ... :-(
-
Und sowohl im aktuellen Datenblatt als auch per schriftlicher Aussage von TI im Zuge der Fehlersuche ist das Thermal Pad intern mit Nichts verbunden angeblich.
Nun, wenn TI das bestätigt, dann müssen sie wohl nachforschen, was sie an der Verbindung zum Thermal Pad geändert haben. Üblicherweise jedoch sind Thermal Pads alleine schon aus dem Grund guter Wärmeableitung -- durchaus auch elektrisch leitfähig -- mit dem Substrat/Die verbunden und können nicht auf beliebige Spannungen gesetzt werden. Z.B. aus dem Datenblatt eines NXP 74LVC8T245 (nicht TI), das ich gerade zur Hand habe:
"the substrate is attached to this pad using conductive die attach material. There is no electrical or mechanical requirement to solder this pad however if it is soldered the solder land should remain floating or be connected to GND."
-
So rein interessehalber: Wie ist das eigentlich ausgegangen? TI schreibt ja in den FAQ zu ihren Logik-Produkten sogar "The thermal pad may be connected to the ground plane or left floating." Also raten sie davon ab, es z.B. auf Vcc zu legen, wohl aus gutem Grund -- auch wenn es im Prototypen wohl (durch Glück?) gut gegangen ist.
-
Ein ausführlicher Artikel ist schon seit ein paar Tagen in der Übersetzung bei uns. Die ganz kurze Version. TI behauptet sowohl in den Dokumenten zum Bustreiber, als auch in einem Statement, daß das Thermal Pad intern "not connected" sei. Auch in PCNs zum Produkt sind keinerlei Änderungen vermerkt.
-
Hintergrund meiner Frage: Von einem anderen Hersteller kenne ich es wie folgt: Das Substrat ist über Wärmeleitkleber mit dem Thermal Pad verbunden. Damit ist es auch da formell "not connected". Allerdings rät dieser Hersteller aufgrund der sehr dünnen Kleberschicht davon ab, auf deren Isolation zu vertrauen. Daher soll man Masse anlegen oder das Pad unverbunden lassen, weil man sonst evtl. das Substrat auf ein anderes elektrisches Potenzial bringt, was zu Fehlfunktionen oder zur Zerstörung des ICs führt.
Nachdem TI in ihren FAQ auch den Hinweis mit "Masse oder unverbunden" bringt, hatte ich erwartet, dass Ihr dort auf einen ähnlichen Effekt gestoßen seid. Vielleicht ist der Satz ja auch erst nach Eurer Reklamation die FAQ gekommen?
-
Also so genaue Hinweise wie von dem Anderen Hersteller gibt es von TI nicht. Ob die FAQs nachträglich geändert worden sind, kann ich natürlich auch nicht sagen.
Unsere Hardwarejungs spekulieren abschließend damit daß die Zusammensetzung vom Diebond Material geändert wurde, was aber nirgens dokumentiert ist.
-
Der Artikel ist seit heute Vormittag online, für Alle die es genauer interessiert:
http://firebee.org/fb-bin/news?&lng=DE
-
Interessant zu lesen, vielen Dank!
Ein paar Anmerkungen:
1. Tippfehler in der Bauteilnummer im Text. Dem Screenshot kann man entnehmen, dass es um SN74LVC8T245 geht.
2. Ich nehme an, ihr habt es nicht geschafft, von TI eine verbindliche Aussage zu bekommen, ob man denn nun Vcc mit dem Thermal Pad verbinden darf? Denn würden sie mit "ja" antworten, würden sie zugeben, dass ihre ICs mangelhaft waren; würden sie mit "nein" antworten, würden sie zugeben dass ihre Dokumentation unvollständig war.
3. Beim SN74LVC244A hat dieser Satz kürzlich Eingang ins Datenblatt gefunden: "TI recommends to connect the exposed thermal pad to ground for best thermal performance. Must not be connected to any other pin than ground."
In der Version Z vom Januar 2015 steht er noch nicht drin: http://hands.com/~lkcl/eoma/microdesktop/sn74lvc244a.pdf (http://hands.com/~lkcl/eoma/microdesktop/sn74lvc244a.pdf).
In der Version AB vom November 2016 steht er drin: http://www.ti.com/lit/gpn/sn74lvc244a (http://www.ti.com/lit/gpn/sn74lvc244a). Hmm...
-
Danke für den Typo. Ist ausgebessert!
2. Ich nehme an, ihr habt es nicht geschafft, von TI eine verbindliche Aussage zu bekommen
Das finde ich jetzt interessant, daß für Menschen die sich mit der Materie auskennen, wie Du, das so sonnenklar ist. Ja, natürlich haben wir nichts ganz Konkretes bekommen: zwar "internally not connected" aber "Connecting thermal pad to supply plane or signal traces are not recommended". Alles im Nachhinein natürlich. ;)
3. Beim SN74LVC244A hat dieser Satz kürzlich Eingang ins Datenblatt gefunden: (…) Must not be connected to any other pin than ground."
In der Version Z vom Januar 2015 steht er noch nicht drin: In der Version AB vom November 2016 steht er drin:
Und das ist jetzt super spannend. Na vielleicht hilfts ja Anderen jetzt wenigstens, …
-
Der Artikel ist seit heute Vormittag online, für Alle die es genauer interessiert:
http://firebee.org/fb-bin/news?&lng=DE
Ein sehr interessanter Artikel. Und eine ganz bittere Pille, die da nun zu schlucken ist. Es dürfte schwer fallen, TI zur Übernahme einer Teilschuld zu bewegen. Was ich daraus lerne ist, daß es bei Folgeauflagen sinnvoll erscheint, zunächst erneut ein paar Prototypen anzufertigen und diese nochmals zu testen, bevor man dann einen zeitnahen Produktionsauftrag vergibt.