Rotel RSX 1067 - problém na digital boardu

[DonKarlos]

hrálo, já vím :-) S tím Atmelem ... můžu ho vypájet a vyzkoušet v programátoru, jestli ho načte. Ale co tam má být nahráno, to nevím.

[jardag69]

Zkus hledat závadu tam, kde by mohla být. Jestli na nějakém konektoru nejsou ty trhliny v letování. Mohlo se to zhoršit, když si konektory odpojoval. Pak kolem te pameti, jestli jsi to dokonale vyčistil. Netuším, jak hodně to bylo tekuté a jestli to zateklo i mezi nožičky pameti.
Ten ubytek 0.3V vypada na nějakou zradu.

[DonKarlos]

Konektory by měly být OK. Kolem toho supercapu byl vysypaný takový prášek. Stačilo to vyfoukat vzduchem. Kolem paměti to vypadá čistě. Je otázka, k čemu ta paměť vlastně je. Ono totiž těch 5V ze supercapu ještě jde do MCU a RAM paměti u MCU. Asi to není jen záloha pro Atmel. Tipnul bych si, že v atmelu bude uloženo uživatelské nastavení a ve flash paměti firmware.

Ještě si říkám, zda nevadí toto (napětí):


V datasheetu k DSP obvodu se uvádí:


Na osciloskopu bylo nastaveno měření V_high. Když je nastaveno na V_rms, tak měří cca 3,35V. Ale bylo i víc. Nevím, na kolik můžou špičky vadit. Určitě to ale ní ideál.

[jardag69]

Si ty špičky roztáhni, at neco vidíš. Už si našel, kde se ti ztrácí 0.3V ?

[DonKarlos]

Asi to kašlu. Ten receiver si ze mě dělá akorát prdel. Dnes ho zapnu, a 4,95V. Si připadám jak debil :-(

a včera:
https://youtube.com/shorts/l9lwFvUpI-Q?feature=share

špičky zde



a po čase se to chová jako včera. Asi se to mění s teplotou

[jardag69]

Pokud to měříš na stabilizátoru a jiné to nedělají, tak zkus vyměnit ten elyt 1u0. Pokud je to nekde dál, tak je tam jiný problém. Jestli ti to každý den měří jinak, tak zkus najít studenák.

[DonKarlos]

Jen pro porovnání ...
kanál 1 - měřeno +5VA na DAC (kanál je na Y posunutý o 1V níž oproti kanálu 3. Ať se průběhy nekryjí)
kanál 3 - měřeno +5VA na výstupu ze zdrojové desky



Tentokrát jsem ověřoval i sondy, jestli měří stejně. A měřily stejně. Budu tedy hledat studeňák. Ale dostanu se k tomu až večer. Možná.

Studeňák jsem zatím nenašel. Zkusil jsem pájkou prohřát spoje na konektorech. A taky jsem zkusil přečíst tu Atmel paměť. Zdá se, že by měla být v pohodě. Z desky jsem ji netahal. Měl jsem strach, že poškodím desku. I když mám k dispozici nahřívací odsávačku, jde to stejně blbě. Tak jsem to prodrátkoval. Nejsou v ní sice souvislá data, ale myslím, že by to nemuselo vadit. Možná jsem mohl zkusit ji smazat a znovu nahrát. Při čtení se možná chybné paměťové buňky neprojeví. Nevím.

[jardag69]

Tak to vypadá, že budeš muset hledat na datových linkách. Proč se ti neaktivují DACy a co do nich případně jde za data. Nezávidím. Ve finále to bude nějaká součástka za 5 korun.

[DonKarlos]

jsem nedávno měřil na DSP. Do DSP nějaké audio data šly, z DSP do DAC už ne. Otázka je, proč. Těch možností je hodně :-(

Pořád se mi nezdá signál Clock pro komunikaci MCU <-> DPS. Když je to hodinový signál, tak by měl být pravidelnou periodu, ne? Zkusím se píchnout na krystal MCU

Clock:



mohlo by to vysvětlovat, proč se občas receiver kousnul a na nic nereagoval. Jen na odpojení od sítě. A taky občas pozoruji překmity při otáčení volume. Pomalu točím a někdy se stane, že se hlasitost skokově změní.

[jardag69]

Na krystal se nechytej. Tam jsou občas pro chod potřeba kondíky v řádu piko. To by sonda mohla rozhodit. Najdi si nejaky jiny signal.
Když tak rovnou pis, kde se chytáš. Sosnul jsem si service manual, tak se můžu podívat.
Najdi si pdf na ten obvod, tam byvaji obrazky průběhu signálů.

[DonKarlos]

používám servis manuál V02. Mám novější typ desky. Ale na moc změn, oproti klasickému manuálu, jsem nenarazil.

No jo, ale kde se potom chytit, abych ověřil clock signál MCU? Napadá mě jen signál FRT.CLK na MCU, který slouží ke komunikaci s procesorem na předním panelu u displeje. Tak to chápu já.

Na poslední fotce je změřený průběh na signálu 49..CK, který najdeš na stránce u zapojení DSP v levém dolním rohu. Jde na dva vstupy DSP označené jako SCCLK a FAO, FSCCLK. V dokumentaci DSP se píše, že tyto signály jsou hodinové. Tak předpokládám, že hodinový signál by měl mít konstantní šířku pulzu. A ne, že to bude lítat jako na fotce. Bylo to vidět i na videích, co jsem tu dával odkazy. Na druhou stranu, měřil jsem další dva signály z MCU s označím CK na konci, a chovaly se stejně , nebo podobně jako ten 49..CK. Viz video. Ale říkám si, co když je to zkrátka špatně. Třeba ty obvody přepínání vstupů a ovládání hlasitosti takový signál zvládnou, ale DSP už ne. Nevím.

edit: AI poradila, že by na MCU mohl být CLK out. Jestli to chápu správně, tak u tohohle MCU by to mohl být výstup CLK na pinu č.36. Podle dokumentace k MCU by to tak mohlo být.

[kaed]

Pomalu točím a někdy se stane, že se hlasitost skokově změní.

tohle dělal můj historickej receiver, ale to byl jasně vyšlehanej enkoder na kolečku hlasitosti. A tohle nezačne z ničeho nic, tj u tebe to bude pravděpodobně něco jinýho.

[jardag69]

Hmm, co signal na SCOUT pin 55. Tam by měl byt polovični kmitocet jak na krystalu. Sice je to označene jako vstup, ale co už. Tam by se asi dalo chytit. Na TMP95C063

[DonKarlos]

na pin 55 SCDOUT se posílají data z DPS. Na houby je, že při bootování DSP se třeba posílá 0x00 00 00 01, což by mělo být 00000000 00000000 00000000 00000001 binárně. Tomu by měl taky odpovídat signál clock. Předpokládám. Jenže chodí to co chodí. Potřeboval bych to nějak synchronizovat. Chtělo by to ještě 2 sondy :-) Nebo lépe, nějaký analyzátor komunikačních rozhraní :-D Protože těch signálů, co do té komunikace kecají, je víc.

Signál 49..FCS -> aktivní stav je log.0 -> ten by měl označovat začátek a konec přenosu dat (platí pro dekodér DSPAB)
Signál 49-INTREQ -> aktivní stav je log.0 -> když je "0", oznamuje MCU, že má data k přenosu (platí pro dekodér DSPC)
Signál 49-FINTREQ -> aktivní stav je log.0 -> když je "0", oznamuje MCU, že má data k přenosu (platí pro dekodér DSPAB)
Signál 49-FSCDIO -> Určuje komunikační režim DSPAB během bootování
Signál 49-SCDOUT - data z DSP do MCU
Signál 49..SCS -> aktivní stav je log.0 -> ten by měl označovat začátek a konec přenosu dat (platí pro dekodér DSPC)
Signál 49..DO -> data z MCU do DSP
Signál 49..CK - clock

podle AI by to mělo fungovat tak, že:
Host stáhne RESET nízko, nastaví FHS/UHS, poté RESET pustí nahoru.
[alldatasheet.com]


Host po RESETu pošle DSPC zprávu:
C_MASTER_SOURCE_MODE (případně MASTER_BOOT_FLASH).
→ tím DSPC ví, z jaké FLASH má bootovat DSPAB.
[alldatasheet.com]


DSPC provede inicializaci a pošle:
C_BOOT_START
[alldatasheet.com]


Host uvolní sběrnici (DSPC si čte FLASH samo).


Po dokončení nahrání DSPAB DSPC pošle:
C_BOOT_SUCCESS nebo C_BOOT_ERROR_CHECKSUM
[alldatasheet.com]


Host nyní opakuje proces, ale tentokrát bootuje DSPC image.


Po úspěšném nabootování DSPC pošle:
C_APP_START
[alldatasheet.com]


Host provede:

hardware konfiguraci DSPC,
software konfiguraci DSPC.



DSPAB vyšle svůj vlastní signál:
AB_APP_START
[alldatasheet.com]


Host nakonec pošle KICKSTART zprávu → DSP začne dekódovat.

Tož asi tak :-D :-D

edit:

[jardag69]

Stejně bych zacal tim, proc se obcas ztraci napajeni digitalu.

[DonKarlos]

jak to myslíš s tím že se ztrácí napájením digitálu?

Jinak, měřil jsem na tom výstupu CLK na MCU a naměřil jsem relativně hezký pravidelný hodinový signál o frekvenci 6,154MHz. V dokumentaci je psáno, že výstupní frekvence je frekvence krystalu vydělená čtyřmi. Takže to sedí.

Včera jsem měřil napájecí napětí na různých místech. Na DSP (PLLVDD, 2,5VD), na paměti DSP (3,3V), na supercapu (M+5V), na DAC (každé zvlášť, 5V, 3,3V), na přepínači dig. vstupů (3,3V, 5V). Vše se zdá být v pořádku. Napětí 3,3V je trochu vyšší (Vh=3,5 až 3,6V; Vrms=cca 3,45V).

Chtěl bych nějak zachytit tu komunikaci mezi DSP a MCU abych věděl, zda DSP nabootuje. Ten signál 49..CK se mi prostě nelíbí. Dnes jsem ho zase měřil a kromě toho, že mění šířku pulzu, se mi taky nelíbí, že když během měření mačkám stále dokola tlačítko režimu stereo/bypass, tak signál není nikdy stejný. Prostě se přepíná mezi 2 režimy, tak bych pochopil, že se třeba budou střídat dva průběhy signálu. Ale ne, pokaždé je jiný. A když se podle dokumentace mají příjimat a odesílat 32 bitové zprávy, čekal bych na hodinovém signálu odpovídající počet pulzů. A to nesedí.

[jardag69]

V pár postech si psal, že se ti někde mění napětí na 5V a to až pod minimální doporučené. Zatím si nepsal, že bys našel, proč se to děje.

[DonKarlos]

jo tohle ... to bylo napětí pro analogovou část DAC. Nachystal jsem si drátky a měřil jsem to přímo na vyhlazovacím kondenzátoru u každého DAC. Měl jsem nachystané drátky na + i - na tom kondenzátoru. A včera to bylo OK. Prohřál jsem spoje na napájecích konektorech na řídící desce, i na desce výstupní, ze které vede GND signál k analogové části DAC. Nevím, co s tím víc dělat. Navíc, když bylo napětí v pořádku, stejně to nehrálo. Tak jsem šel od toho.

Nevím jestli se třeba nemrknout na řízení v předním panelu. Jestli není problém třeba tam. Ale když ovládání apod. nějak funguje ...

[jardag69]

Hmm, tohle je už je na mě moc a stejně by to takhle na dalku byl akorat zmatek. Dej vědět, jestli něco najdeš.

[DonKarlos]

Podle pořekadla "tonoucí se stébla chytá" jsem se rozhodl jít víc do hloubky a omrknout i zbylé komponenty. Všiml jsem si totiž, že při připojování reprobeden se aktivoval triger na osciloskopu, když jsem byl sondou chytnutý k tomu CK signálu. Tak mě napadlo, zda třeba není nějaký problém se zemí u terminálu k bednám. Už prostě nevím co, tak zkouším všechno možné. Když jsem měl většinu komponent venku, využil jsem situace, a vyrovnal jsem kovové šasi, protože bylo bylo v jednom místě promáčklé. Levá zadní nožka byla propadlá. Receiver se kolíbal. Asi utrpěl v minulosti ránu. Viditelné stopy jsou i na předním panelu, kde je mírně ohnuté hliníkové žebro. Při tom jsem ho i vyfoukal vzduchem od prachu. Zatím vypadá viz foto :-) Chci omrknout pod lupou ten přední panel. Pak to zase poskládám. Na ostatních deskách jsem si ničeho nevšiml. Zkoušel jsem procházet i fóra, kde se věnují MCU a komunikacím. Narazil jsem na diskuzi, kde řešili problém s Clock signálem. Někdo tam psal, že špatný Clock signál může být způsoben i konfliktem na sběrnici. Vznesl jsem dotaz na můj případ, ale zatím nebyla odezva. Uvidíme