Roland Jupiter 6 hängt

Bassliner303

Bassliner303

.....
Ich präzisiere nochmal meine Aussage ;-)

Synth eingeschaltet (ohne Brücke) bootet nicht 0,01V... Eingeschaltet (mit Brücke) Synth funktioniert 1V.

Werde mal TR15 austauschen und melde mich dann nochmal.
 
Bassliner303

Bassliner303

.....
Also da riecht nix, qualmt nix. Aber um Missverständnisse auszuschließen - ich habe hier gemessen (linke Seite von R23)

PS: Sehe gerade dass TR15 wohl TR12 sein müsste.

IMG_20191209_003701.png
 
Zuletzt bearbeitet:
Bassliner303

Bassliner303

.....
Ich melde mich wenn ich den neuen TR eingelötet habe. Vielen Dank bis hier. Wenn die Kiste dann wieder läuft bekommst Du ein Bier oder eine Tüte Gummibären :)
 
Bassliner303

Bassliner303

.....
Guten Abend zusammen!

Ich wollte mich hier nochmal ganz herzlich für die Hilfe bedanken :) Der Jupiter läuft wieder einwandfrei. Ich habe zur Sicherheit beide Transistoren (TR12, TR13) getauscht.
TR12 war aber letztlich der Übeltäter.

Eventuell kann mir der nette Helfer ja eine PN schicken, würde mich gerne erkenntlich zeigen.

Habt eine schöne Vorweihnachtszeit.
Gruß, Andy

Jupiter-6.jpg
 
Zolo

Zolo

.....
Also es ist wirklich seltsam.. Alles was ich teste funktioniert.
Nur die LEDs sind (wie beim letzten Patch) an und kein Taster reagiert.
Arp. Rate verändert die Geschwindigkeit des Blinkens des Arps.

Getest: Strom -> alles wie es soll.
RST-Signal nach dem Anschalten wie es soll.
Master Clock Signal IC20 auch vorhanden.

Wenn ich das richtig sehe, geht ja auf dem CPU Board auf der rechten Seite über einige IC (z.B. 22 und IC23) zum Panel mit den LEDs. An den IC's sehe ich auch einiges ankommen, aber weiß nicht wie das Signal aussehen soll.
Kann man in dem Bereich mit dem Oszilloskop etwas überprüfen?
 
Zolo

Zolo

.....
Korrekt. Das könnte auch sein, dass die Daten im SRAM korrumpiert sind, und er deswegen hängt. Das kann durch ... oder auch durch einen schnöden Bit-Kipper (so kann auch vorkommen) im SRAM.
Mal angenommen es wäre so. Was könnte man in dem Fall unternehmen? Müsste zwangsweise ein neuer SRAM rein?
 
fanwander

fanwander

*****
Mal angenommen es wäre so. Was könnte man in dem Fall unternehmen? Müsste zwangsweise ein neuer SRAM rein?
Nein, da geht es um Inhalte. Wenn das der Fall wäre dann müsste die Tape-Funktion gehen. Damit könntest Du Default-Patches einspielen.

Kann man in dem Bereich mit dem Oszilloskop etwas überprüfen?
Ja kann man. Ich habe aber jetzt Gäste...
 
Zolo

Zolo

.....
Ich hab in englisch ein Thread mit genau dem selben Problem gelesen. Auch ohne Europa:

Problem is: I turn it on but I can't switch any of the patches etc. The only things I can turn on an off are the left side controls by the pitch bender. Also it makes no sound.

Dort schreibt jemand interessanterweise:
this happened to my friends Jupiter 6...or at least it extremely similar. We were able to fix it by sending it a specific control change from the computer. I don't remember if the local was just turned off or what, but I remember the it was a higher cc#, right near the end of them.
Ich denke aber er bezieht sich bestimmt auf einen mit Europa Mod oder?

Leider wird es im Thread nicht aufgelöst. Letzter Eintrag: er hat eine neue Batterie bestellt.
 
Zolo

Zolo

.....
Hey zusammen. Ist es normal dass auf dem Modulboard beim IC6 das Reset Signal nur 3,5 v erreicht?
 
Zolo

Zolo

.....
Super danke!
Ich habe auf dem CPU Board im Rst Signal nur 4,2 - 4,5 V.
Kann das noch im grünen Bereich sein, weil der Transistor von der Reset Schaltung 0,6V abzieht?
Das wäre ja quasi auch beim IC9 womit man dann auf 3,5V kommt?

Mein Reset Signal ist auch nur 40ms statt 80ms auf dem CPU und den Modul Boards.
Aber sind das nicht genug und mehr als die 24 Clock Cycles?

Denke es könnte ein Problem mit IC8 oder IC9 bei mir sein...


Nö. Wenn die Kiste eingeschaltet ist, dann sollte IC9 (40H002) auf dem CPU-Board (der erzeugt das Signal) (fast) 5V Versorgung haben (an Pin 14, kommt über D1 aus den "entstörten" 5V="A" im Schaltplan) und der Ausgang demzufolge auch fast 5V sein, ist ja ein CMOS-IC.
 
Zuletzt bearbeitet:
Zolo

Zolo

.....
Also IC9 Pin 14 sind 4,96V wie bei den meisten anderen auch. Nur bei IC8 und IC24 liegt 4,2V an?
 
Zolo

Zolo

.....
Also mal ein Zwischenbericht was wir jetzt alles probiert haben:
Die 5V (4,96) vom RST Signal kommen auf beiden Modulboards an und werden dort durch von dem jeweiligen Buffer IC3 gepuffert und verlassen mit 3,5V Richtung CPU. Da es bei beiden Modulboards identisch ist, gehen wir davon aus, dass es nicht am Modulboard hängt.

Wie oben für Bassliner empfohlen, haben wir den R51 kurzgeschlossen, um ein künstliches Reset Signal auszulösen, aber mit gleicher Wirkung. Sprich 3,5V und 40 ms. Deswegen würden wir Reset auch erstmal aussen vor lassen.

An D2 Diode auf dem CPU Board fallen im Batterie BEtrieb 0,2 V ab und wenn der Synht an ist fallen bei D1 0,8 V ab. Also werden aus 5V dann 4,2V und speisen das RAM-TONE und IC8.

Wir haben versucht den Logic Signalweg Richtung LED Abfrage zu verfolgen. Wir können in erster Linie nur schauen DAS etwas geschickt wird, aber wissen nicht ob das richtige gesendet wird.

Wir haben uns die Bus Treiber / Transceiva (245) angeschaut und da nach den Enable auf Pin 19:
Er wird enabled bei IC22 und IC14.
Bei IC23 (Zusändig für Schalterdaten) und IC27 (Zust. für Keyboard Daten) werden NIE enabled.
Die Enable Leitung haben wir zurückverfolgt Richtung CPU und da kommen wir an den Decoder (138 / IC19). Es sieht nicht so aus, als sei der Decoder kaputt weil er andere Leitungen wie RAM (IC25) bedient bzw. ansteuert, aber fragt die beiden nicht ab.

In Richtung Schreiben haben wir bei IC18 angeschaut... Wird von der CPU angesteuert, aber schickt nie etwas raus.
 
Zuletzt bearbeitet:
Zolo

Zolo

.....
Hi und danke für die schnelle Antwort ;-)
Also die Spannung fällt um 0,8V ab auf 4,2V. Ich habe mich da etwas unglücklich ausgedrückt.

Weiß denn jemand zufälligerweise wieviel Volt das Reset Signal von den Modul Boards gebracht hat?
Oder hat vielleicht jemand einen Jupi6 offen und kann mal nachschauen?

Die nächste Idee wäre jetzt Eproms zu kaufen um auszuschliessen, dass ein Bit Kipper etwas durcheinander bringt.
Ansonsten wären wir über Ideen oder Gedankengänge zur Insperation glücklich, wo man noch ein Auge drauf werfen könnte oder in welcher Richtung man denken könnte?

Liebe Grüße Zolo
 
Zolo

Zolo

.....
Also Update:
Haben Eprom ausgelesen und ist 1:1 identisch mit dem V6 was man Internet bekommt. Die beiden Eproms von den Voice Boards sind auch in Ordnung.

Dann haben wir auf ein anderes Eprom das Factory OS draufgespielt. Dort wird einiges getestet und die Factory Sounds neu drauf geladen.
Ergebniss: A8 also alles ok.
Mit dem Test Eprom sind übrigens alle LEDs am Panel dann aus bis auf die Bank/Program die dann den Status (richtig anzeigen).
Also bei aktiviertem Memory Protection wird dann richtig A4 angezeigt. Funktioniert also richtig.

Nachdem installieren des alten Eproms ist dann wieder genau die LED Konstellation, wie beim letzten Patch als er noch ging.

Anbei nochmal aus dem Readme was dort getestet wird:

USING FACTORY

Factory is quite simple to use. Now that it is installed, turn on the Jupiter
6. You will get a code in the form of lights on A-F and 1-8:

A 1 - External scratch RAM failure. This means that the code was unable to
read/write an image to the external scratch RAM within the control
board. The most likely cause of this is a defective SRAM chip. This
does NOT indicate a failure with the non-volatile RAM.

A 2 - Internal CPU RAM failure. This code means that the memory built into
the 8031 (or 8051 if so equipped) is defective. The main processor
should be replaced.

A 3 - NVRAM read/writes unreliable. FACTORY Will attempt to run a memory
check on the non-volatile RAM, and if this memory test fails it usually
means a low battery. If the battery is 3 volts or stronger, then the
problem is most likely with the NVRAM chip itself.

A 4 - Memory protect is turned on. FACTORY Can't do its work if you have the
board's write protect on. Turn off the board, turn the write protect
off, and turn the board back on again.

A 5 - Failure while writing information to NVRAM. In addition to the tests
originally run on the NVRAM, the data pulled from the FACTORY EPROM
is verified when written to the non-volatile RAM. If, during this
step, data read back from NVRAM doesn't match what was supposed to be
written, this code will be presented.

(there are no A 6 or A 7 codes)

A 8 - This indicates a successful NVRAM write with the factory patches.
 
fanwander

fanwander

*****
Eehm... Warum betonst Du "Factory OS" ist das eigentlich ein mit Europa erweiterter JP6???


Und dann: was ist jetzt der Zustand? Deine letzte Meldung klingt fast so als ob alles OK wäre. Oder geht er mit dem Factory OS auf dem neuen EPROM wunderbar - aber nicht mit dem "alten" (also vorher eingebauten) EPROM?

Irgendwie ist die Situation momentan sehr unklar.
 
Zuletzt bearbeitet:
Zolo

Zolo

.....
Du meinst das ist das Factory OS für Europa?

Jedenfalls interessant zu sehen, dass es geklappt hat :D Ohne Europa ;-)
 
fanwander

fanwander

*****
Oder besser: war er bis zu dem Moment, wo er kaputt gegangen ist, einer mit Europa?
 
Zolo

Zolo

.....
Achso meinst du. Nein er ist schon immer Original ohne Europa ;-)
Zustand: immernoch dieser Freeze. Reagiert nicht. Taster leuchten wie beim letztem Patch, aber Taster reagieren nicht.

Das OS Eprom ist wohl nur um ihn intern zu flashen. Sonst hat der Synthi dann keine Funktion. Aber das Flashen klappt.

Ok ist irgendwie nur alles was wir auf der Platine messen und testen :D Wie verhext...
 
fanwander

fanwander

*****
Achso meinst du. Nein er ist schon immer Original ohne Europa ;-)
Zustand: immernoch dieser Freeze. Reagiert nicht. Taster leuchten wie beim letztem Patch, aber Taster reagieren nicht.

Das OS Eprom ist wohl nur um ihn intern zu flashen. Sonst hat der Synthi dann keine Funktion. Aber das Flashen klappt.

Ok ist irgendwie nur alles was wir auf der Platine messen und testen :D Wie verhext...
Ich könnte mir Vorstellen, dass die Verbindung zu den Panelboards einen Hau haben, bzw ggf sogar die Multiplexer auf den Panelboards. Kuckt mal mit dem Scope ob die 4067 auf den Panelboards Adress-Daten und INH bekommen. Die Taster werden ja direkt als Matrix abgefragt. Da muss auch regelmäßig auf den Bussen was kommen. Das ist jetzt halt alles nichts mehr, was man so auf die Schnelle per forums-Post erklären könnte.
 
Brap

Brap

..
Hallo zusammen,
ich bin kein Musiker sondern Elektroniker und versuche zusammen mit Zolo den JP-6 zu reparieren.

Die heutige Debug-Session hat eine Erkenntnis gebracht: Das CPU Board ist okay. Es wird von den Modul Boards angehalten. Und zwar sind die Leitungen "FROM MOD BUSSY" beide auf High. Wenn wir die Stecker MC4 von den Modul Boards abziehen, dann läuft die CPU und die Taster werden abgefragt, die LED folgen den Tastern. Auffällig ist: Beide Modul Boards sind der Meinung, die Main CPU sollte nun mal warten. Nur ein Modul Board abziehen bringt nichts.

Nun ist die Frage, warum die Modul Boards das tun. Die BUSSY Leitungen gehen direkt zu den TX Pins 11 der Slave CPUs. Es muss eine Ursache geben, die auf beide Modul Boards Einfluss nimmt. Was wir auf den Modul Boards geprüft haben:
  • Alle Versorgungsspannungen sind okay
  • CPU Takt ist okay
  • Reset Signal ist Low (wobei der Einschalt-Reset nur 40 ms dauert und der Reset-High Pegel 3,8 V beträgt)
  • Auf dem Bender-Board alle Stecker abgezogen - keine Änderung
Das Service Manual von Roland sagt zu diesem BUSSY Signal:
Bildschirmfoto 2020-01-12 um 20.25.56.png
Ich verstehe zwar die COMPU TUNE Schaltung mit IC 4 und IC 20. Der Zweck ist mir jedoch schleierhaft. Der Ausgang des OPVs IC 4, also Int0 der Slave CPU, ist übrigens immer High. Ich denke die Slave CPUs werden nicht fertig mit dem "Computune", komme an dieser Stelle aber nicht weiter. Kann uns jemand erklären was da passieren soll?
Bildschirmfoto 2020-01-12 um 20.42.00.png

Gruß
/rainer
 
Zolo

Zolo

.....
Super, danke ;-)
Ich habe was auf Gearslutz in dem Bereich gefunden:

Usually an analog synth tuning algorithm works by measuring the frequencies of the VCOs, one VCO at a time, by returning their signal to a frequency counter or comparator IC (there are CMOS switches involved in the routing of the signal back to the counter/comparator). On the Jupiter 6 this is being handled directly on the voice cards, where the schematics identifies the Auto-Tune circuitry as COMPUTUNE. The voice card's CPU, by means of the comparator/counter circuit, measures the VCOs over a range of frequencies and calculates an offset that is being added to the VCO control voltages, in order to make the oscillators producing the right frequencies (= the right notes). When all the VCOs are tuned the voice's board CPU notifies the instrument's main CPU that its job is done.

If all the oscillators on a voice card don't tune the problem could be in the Autotune circuitry, and it usually regards the CMOS switch ICs and/or the comparator/counter chip. The CMOS switches used in analog synthesizers usually are the 4000 series ICs, quite well known today as a common failure point. And if the Autotune circuitry is faulty it's possible that is driving that voice board's CPU crazy, resulting in the whole synth freezing when trying to invoke the autotuning function from the panel.

To diagnose the computune circuit I'd start to scope the output of its 4051 CMOS switch (IC20, pin 3) to see if there are VCO signals coming out from it when the Autotune procedure is being invoked from the panel.

Another failure could be in the CV DAC, which in the Jupiter 6 is the now (unfortunately) rare Intersil ITS80141, and there's one on each voice card. To see if the problem resides in the DAC, with the synth set in WHOLE mode make a patch with just white noise and with the filter/amp being modulated by their EGs. If the patch sounds quite consistent over all voices (play different keys so different voices will be fired), both the DACs are OK. If not, compare with the oscilloscope the output of IC12 (the DAC's output op-amp, which is a TL081) on the voice cards, which should look similar for both. If this is the case the DAC is OK and probably there's a problem in the S/H demux circuitry after it, which is full of 4051 CMOS switches and TL084 op-amps, the latter again being a common failure point in analog synthesizers. If not, the DAC's output op-amp or the DAC itself on the 4-voice board could have failed.
 
Brap

Brap

..
Super, das hilft sehr. Dann hoffen wir mal dass es nicht der DAC ist. Dieser ITS80141 ist nur zu Mondpreisen erhältlich.
 
Zolo

Zolo

.....
Oh super, danke!

Zwischenbericht: Wir haben einen Oszillator gefunden, der nichts ausgibt. Bei der nächsten Session geht es darum herauszufinden ob der Curtis Chip kaputt ist oder einer der umliegenden Bauteile.

Für Anfänger die wegen einem Defekt des Jupiters googeln:
Der Synthi hat eine Testroutine nach dem Anschalten. Dort werden auch alle Oszillatoren automatisch getuned. Funktioniert das nicht, weil bspw eine OSC defekt ist, startet der Jupiter nicht (fällt in eine Art Sicherheitsmodus) und bleibt einfach hängen. Also anders wie bspw. einem Juno 106, der auch erstmal mit defekter Stimme weiterhin spielbar ist.
 
Zolo

Zolo

.....
So ich muss jetzt mal was lustiges frage: stimmt das überhaupt was ich hier geschrieben habe ? :schwachz:
Der Synthi hat eine Testroutine nach dem Anschalten. Dort werden auch alle Oszillatoren automatisch getuned. Funktioniert das nicht, weil bspw eine OSC defekt ist, startet der Jupiter nicht (fällt in eine Art Sicherheitsmodus) und bleibt einfach hängen. Also anders wie bspw. einem Juno 106, der auch erstmal mit defekter Stimme weiterhin spielbar ist.
Oder kann es sein, dass der Jupiter trotz defekter Stimme startet ?

Und wo ist denn der LFO1 angesiedelt? Scheint von der CPU zum Panel Board zu gehen. Aber da muss es doch noch mehr geben, oder?
Habe den Verdacht, dass was nicht stimmen könnte bzw. es gerne überprüfen.
 
Brap

Brap

..
Okay, hier mal was ich meine verstanden zu haben und was ich nicht verstehe:

Wie Zolo bereits geschrieben hat, haben wir einen VCO gefunden der nicht schwingt. Könnte das die Erklärung sein, warum das Computune nie fertig wird? Jein!

Wir haben uns gestern den Computune Ablauf an dem nicht defekten Modulboard (das Linke mit vier Stimmen) angesehen. Die Slave CPU zählt die Adresse des zu tunenden VCOs an IC20 von 7..0 runter. Dabei laufen die selektierten VCOs mit unterschiedlichen Frequenzen und die Impulse kommen an INT0 der CPU an. Dann macht die CPU noch einen (schnelleren) Durchlauf über alle acht VCOs, springt danach zu Adresse 7 und bleibt dort stehen.

Das Computune auf dem defekten Modulboard (das Rechte mit zwei Stimmen) zählt die Adressen von 7..3 runter. Die werden wohl übersprungen weil nicht bestückt. Bei der Adresse drei, also dem defekten VCO, bleibt der Ablauf stehen. Das ist klar, denn dieser VCO ist nicht einstellbar und es gibt wohl keinen Timeout in der Software.

Was ich nun nicht verstehe: Auch bei dem linken Modul Board bleibt die BUSSY Leitung nach dem Computune auf High. Also ist auch dieses (vermeintlich nicht defekte) Modul Board der Ansicht, es wäre mit dem Computune noch nicht fertig. Was fehlt da noch damit dieses Modulboard in Betrieb geht?

Wir haben versucht das CPU Board zwangsweise freizuschalten, ohne die Stecker der Modulboards abzuziehen. Dazu einfach R45 kurzschließen. Das funktioniert einwandfrei: Die Bedienoberfläche erwacht zum Leben und die Main CPU schickt auch schön Daten an die Modul Boards (CPU Pin 10) wenn Tasten gedrückt werden. Aber es erklingt kein Ton, denn die Modulboards hängen ja beide noch im Computune.

Unser nächster Schritt ist den defekten VCO zu reparieren. Mal sehen ob dann zumindest das rechte Modulboard die BUSSY Leitung auf Low zieht.
 
Zuletzt bearbeitet:
Brap

Brap

..
Noch einmal zu der Frage, warum beide Modulboards BUSSY sind, obwohl nur eines defekt ist: Ich glaube nicht an einen Doppelfehler.

Wenn der defekte VCO der einzige Fehler ist, müssen die Modulboards sich gegenseitig blockieren. Dazu müssen sie irgendwie miteinander kommunizieren. Dafür bleiben nur die Leitungen T0 und T1. Die führen zur Main CPU und steuern dort die LFO LED. Sie sind aber auch (über Kreuz) untereinander verbunden, sodass die Slave CPUs darüber kommunizieren können.

Bildschirmfoto 2020-01-19 um 12.43.50.png

Das Service Manual sagt auch, dass sich die Modulboards über diese Leitungen synchronisieren.

Bildschirmfoto 2020-01-19 um 12.43.09.png

Das gibt Grund zur Hoffnung, dass ich die Wette mit Zolo verliere und der Jupiter nach der Reparatur des VCO wieder funktioniert.
 
 


Neueste Beiträge

News

Oben