Reparatur der Naim Mu-So 1st Generation

Hallo Forum,

ich habe kürzlich von einem Freund eine defekte Naim Mu-So der ersten Generation erhalten. Diese musste selbstverständlich repariert werden, jedoch sah es im Internet sehr mau aus bezüglich der Informationen über dieses Gerät und auch der Hersteller hält sich eher bedeckt. Nun läuft meine Mu-So wieder und ich habe mir hier ein Konto erstellt, um ein paar Informationen festzuhalten und Menschen bei zukünftigen Reparaturversuchen ein paar Anhaltspunkte zu geben. Zuerst will ich den Defekt, bzw. die Defekte, beschreiben und für alle Ungeduldigen auch gleich das Vorgehen bei der Reparatur. Danach soll noch etwas Prosa folgen über meine Fehlerdiagnose und alles was ich bei der Reparatur so interessant fand, je nach dem, wie viel Lust ich zum Tippen habe.

Ich würde mich freuen, wenn hier etwas technische Diskussion um das Innenleben der Mu-So stattfindet und auch andere von ihren Reparaturen und Reparaturversuchen berichten, so dass hier eine Wissensammlung entsteht, die bei zukünftigen Basteileien und Reparaturen hilfreich sein könnte. Dummerweise habe ich keine Bilder von den Innereien der Mu-So gemacht. Gern könnt ihr auch Fragen stellen zu Details, die ich hier ausgelassen habe und ich werde so gut wie möglich probieren die Informationen nachzureichen.

Also, Mu-So auf dem Tisch, anschalten, gucken was passiert. Zuerst leuchtet die Status-LED blau, 6 Sekunden später wird sie rot. Das einzige, was das Manual dazu zu sagen hat, ist folgendes:

System fault or amplifier overload (contact your retailer or mu-so suport)

Tja, soweit war ich auch schon. Das "Display" der Mu-So hat nur irgendwelche wenig hilfreichen Striche angezeigt. Was war nun kaputt? Eine 36V Zenerdiode im Netzteil hat dafür gesorgt, dass der 36V-Ausgang des Netzteils nicht mehr funktioniert hat. Das war jedoch nicht der Defekt, der zum beschriebenen Fehlerbild geführt hat. Verantwortlich dafür war eine korrupte Firmware. Die Mu-So ließ sich also durch das Aufspielen eines neuen Firmware-Images und durch das Tauschen der kaputten Zenerdiode reparieren.

Tauschen der Zenerdiode
Betroffen war die Zenerdiode mit dem Bezeichner "DW2" oder "DW3" auf der Netzteilplatine. Welche der beiden weiß ich nicht mehr, aber die eine davon hatte nur einer Zenerspannung von 20V. Die kaputte Diode selbst war beschriftet mit "C36 5T". Ich habe sie ersetzt durch zwei 18V Zenerdioden in Reihe, da ich keine 36V Zenerdiode vorrätig hatte.

Aufspielen der Firmware
Die Mu-So hat ein Ethernet-Interface und lässt sich über ein handelsübliches RJ45 Kabel mit einem Router oder einem anderen netzwerkfähigen Gerät verbinden. Wichtig ist nur, dass auf diesem Gerät ein DHCP-Server läuft, deshalb ist ein Router die einfachste Wahl. Die Mu-So bekommt dann eine IP-Adresse zugewiesen unter welcher sie auf Port 80 eine einfache Website bereitstellt. Auf dieser Website gibt es die Option, ein Firmware-Image hochzuladen. Ich habe dem Support von Naim eine Email geschrieben und freundlicherweise eine passende Firmwaredatei zugeschickt bekommen. Diese ließ sich problemlos hochladen.
Nun ist es ja so, dass, wie beschrieben, die Mu-So nach wenigen Sekunden in einen Fehlerzustand übergeht. Ich weiß nicht, ob sie auch in diesem Fehlerzustand die Website zum Firmwareupdate ausliefert, das habe ich nie probiert. Ich habe eine Möglichkeit gefunden, die Zeit bis zum Eintreten des Fehlerzustands auf 5:30 Minuten zu verlängern, dann ist die Website auf jeden Fall erreichbar. Dazu muss man Pin 16 des Networked Media Modules (NMM) vom Mainboard trennen. Das Networked Media Module ist die kleinere grüne Platine, welche auf das Mainboard der Mu-So aufgesteckt ist und mit "CX870-3B-D" beschriftet ist. Dazu lässt sich online ein Datenblatt finden, welches dabei hilft, Pin 16 zu identifizieren. Wenn man das NMM vorsichtig abzieht, Pin 16 um 90° abwinkelt und es wieder aufsteckt, hat man einen Teil der Kommunikation zwischen Mainboard und NMM unterbrochen. Daraufhin kann man dann die Firmware über die Website hochladen, aber man könnte auch probieren ob das geht ohne Pin 16 umzuknicken.

Fehlersuche
Ab hier geht es mehr ins Detail. Ich schreibe das alles auf, damit Leute ergründen können, ob es sich bei ihnen um den gleichen Fehler handelt wie bei mir und um Teile der Mu-So Hardware zu dokumentieren. Das könnte eventuell auch bei anderen Reparaturen helfen.

In der Mu-So sind im Wesentlichen drei Platinen enthalten: das Netzteil, das Mainboard und das erwähnte Networked Media Module. Das NMM ist mittels eines Pinheaders auf das Mainboard aufgesteckt. Das Netzteil versorgt das Mainboard mit 5V und 36V. Außerdem gibt es auf dem Netzteil eine Brown-Out-Detection und einen Temperatursensor, was beides vom Mainboard ausgelesen werden kann. Zusätzlich gibt es noch ein Enable-Signal, welches die 36V-Versorgung einschalten soll, wenn das Mainboard den entsprechenden Anschluss auf HIGH setzt. Die 5V Versorgung ist permanent aktiv. Ich konnte beobachten, dass das Netzteil keine 36V zur Verfügung stellt, jedoch hat das Mainboard diese auch nicht über das Enable-Signal angefordert. Also habe ich als nächstes die Brown-Out-Detection und den Temperatursensor überprüft. Beide schienen zu funktionieren. Der Temperatursensor ist wohl einfach nur ein 100kOhm Thermistor. Die BO-Detection skaliert die gleichgerichtete Netzspannung mit einem Spannungsteiler und überträgt sie mit einem Optokoppler an das Mainboard. Das das Mainboard kein Enable-Signal gibt, obwohl das Netzteil keinen Fehlerzustand signalisiert, hat auf einen Fehler des Mainboards hingedeutet. Ab da habe ich Netzteil und Mainboard getrennt voneinander untersucht.

Das Netzteil
Bla bla... Netzspannung... Bla bla gefährlich Bla bla... am besten einfach nicht reingrapschen. Sicherheitsbelehrung ende.
Das Netzteil trägt folgende Aufschrift(en): Hanny22W300 PCB140404F1
Um zu testen, ob das Netzteil funktioniert, habe ich es ausgebaut und manuell 5V an den Enable-Eingang angeschlossen. Auch dann kamen keine 36V raus. Manche Netzteile möchten eine Last sehen, also habe ich einen 120 Ohm Lastwiderstand an den 36V-Ausgang und einen 22 Ohm Lastwiderstand an den 5V-Ausgang geklemmt. Auch dann keine 36V, zumindest nicht dauerhaft. Bei einer steigenden Flanke am Enable-Eingang hat das Netzteil einen kurzen 36V-Impuls ausgegeben, welcher dann allmählich in Richtung 0V abgesunken ist. Demzufolge ist das Netzteil anscheinend ebenfalls Defekt. Ich habe daraufhin alle diskreten Halbleiter auf dem Netzteil mit der Dioden-Testfunktion meines Multimeters so gut wie möglich überprüft. Diese schienen alle in Ordnung zu sein. Als nächstes habe ich mir den AZ494AP-E1 vorgenommen, welcher die PWM Steuerung im Netzteil übernimmt. Dessen Feedback-Pin (Pin 3) lag auf 4,6V, weshalb die PWM-Ausgabe deaktiviert wurde. Das sollte so natürlich nicht sein. Ursache war, das am error amplifier zwischen Pin 16 und Pin 15 eine positive Spannung anlag. Also habe ich mich in der Nähe der beiden Pins etwas näher umgeschaut, unter anderem bei den Dioden DW2 und DW3. Diese musste ich auslöten, um ihre Beschriftung lesen zu können. Bei der Gelegenheit habe ich sie genauer untersucht und ihre Strom-Spannungs-Kennlinie grob aufgenommen. Eine der beiden Dioden zeigte einen starken Knick bei -20V, wie für eine Zenerdiode üblich. Die andere war beschriftet mit "C36 5T", deshalb vermutete ich, dass es sich um eine 36V Zenerdiode handelt. Jedoch war ihre Kennline deutlich ausgewaschener, so dass ihre Spannung nicht konstant -36V betrug, sondern stark vom Strom abhängig war. Wohlgemerkt, ihre Vorwärtsspannung betrug laut Multimeter unauffällige 0,7V und rückwärts zeigte sie ausreichend Sperrfähigkeit für den Diodentester. Es war also nur bei genauer Untersuchung festzustellen, dass hier ein Defekt vorliegt. Nach dem Austausch dieser Diode lieferte das Netzteil problemlos 36V, auch ohne Lastwiderstände.

Das Mainboard
Um das Mainboard inklusive NMM unabhängig vom Netzteil testen zu können, habe ich es mit einem Labornetzteil versorgt. Zusätzlich habe ich einen 100 kOhm Widerstand an den TEMP-Eingang und 5V an den BO-Eingang angeschlossen, um sowohl den Temperatursensor als auch die Brown-Out-Detection des Netzteils zu emulieren. Trotzdem bestand der gleiche Fehler fort, was auch nicht sonderlich verwunderlich war, da das Mainboard nie das 36V-Enable-Signal gegeben hat. Ich hab ein bisschen rumgemessen ob das TEMP und das BO Signal beim Mikrocontroller (ein STR912FAW46X6) ankommen und ob die Audio-Entstufen (3 Stück STA516B) ein Fehlersignal ausgeben, das sah aber alles in Ordnung aus. Dann habe ich mir das Datenblatt vom NMM (CX870-3B-D) angeschaut und ein UART Debug-Interface gefunden. Darüber kamen auch tatsächlich ziemlich viele Nachrichten, die ich mit einem Logic-Analyzer mitlesen konnte (115200 baud, 8 Bit + 1 Stopbit, kein Paritätsbit, LSB first, nicht invertiert). Ich kann jetzt nicht den gesamten log hier reinkopieren, aber sagen wir mal, es gab ein paar Nachrichten die mich stutzig gemacht haben:

BonjourService::doInitialize starting initialization
BonjourService::registerServiceAdvert:service _Naim-Updater._tcp on port: 80 already in list
BonjourService::registerServiceAdvert -> service _Naim-Updater._tcp added
BonjourService::doServiceRegister
BonjourService::doServiceRegister: Service _Naim-Updater._tcp success
BonjourService::doServiceUnregister
BonjourService::doServiceUnregister service _Naim-Updater._tcp success
BonjourService::doServiceRegister
BonjourService::doServiceRegister: Service _Naim-Updater._tcp success
BonjourService::doServiceUnregister
BonjourService::doServiceUnregister service _Naim-Updater._tcp success
BonjourService::doServiceRegister
BonjourService::doServiceRegister: Service _Naim-Updater._tcp success
BonjourService::doServiceUnregister
BonjourService::doServiceUnregister service _Naim-Updater._tcp success

Ich weiß nicht, was das bedeutet, aber das regelmäßige "register" und "unregister" von irgend einem service schien mir nicht richtig. Dann gab es noch das hier:

sds://>s x08x08se x08x08x08set x08x08x08x08set x08x08x08x08x08set / x08x08x08x08x08x08set /c x08x08x08x08x08x08x08set /cn x08x08x08x08x08x08x08x08set /cne

"x08" ist der Hexcode für Backspace. Da probiert das Mainboard dem NMM eine nachricht zu schicken und das NMM probiert alle Zeichen in dieser Nachricht wieder zu löschen. Das hat mich dazu geführt, den RXD Pin (Pin 16) mal abzuklemmen, um diese Interferenz in der Kommunikation zu unterbinden. Wenn ich dann die vom NMM gehostete Website zum Aktualisieren der Firmware aufgerufen habe, konnte ich folgende Nachrichten am TXD Pin des NMM mitlesen:

DHCP client: got address 192.168.1.3 mask 255.255.255.0
change net state to EIPCFG_DHCP_FINISHED, IP address: 192.168.1.3
WebCfgBaseHandler::getFirmwareID: error.
WebCfgBaseHandler::getFirmwareVersion: error.
WebCfgBaseHandler::getFirmwareDate: error.
WebCfgBaseHandler::getFirmwareTime: error.
WebCfgBaseHandler::getFirmwareVersion: error.

Spätestens da hatte ich die starke Vermutung, dass es sich hier nur um ein Softwareproblem handelt und dass ein erneutes Hochladen der Firmware hilfreich sein könnte, wie es dann am Ende tatsächlich auch war.

So, ich bin dann erst mal mein neues Spielzeug anhören und froh, dass ich es nicht ins Naim HQ einschicken musste. Viele Grüße.