Pioneer AVR HDMI/HDCP problem

[zzattack]

I have an older Pioneer SC-57 which has at least one HDMI problem. Neither of its 2 output ports produced any picture. I've replaced the HDMI transmitter ICs which (according to a thread regarding a Yamaha AVR from the same era) is a likely failure cause.

This is only partially resolved the issue: when the receiver 'produces' the video output, i.e. while showing its own menu overlay instead of passing through an input source, both ports now display perfectly fine on connected displays. However, when switching to any one of its 7 HDMI inputs, no output picture is produced. Moreover, the front panel display flashes a message "HDCP error". The HDMI indicator LED on the front panel does light up, which is usually an indicator of the receiver having a lock on the selected input.

While I do have the service manual for this receiver, I'm unsure how to proceed. Specifically, I would like some help determining which IC(s) are likely involved with anything HDCP related, and/or help in performing further diagnosis. I've attached a picture of the most relevant schematic depicting the digital video block.

[coromonadalix]

you should post a link the the SV if it was found on the web  ..  if not   try to scan them ??


Some of theses receivers / brands    if i recall  had some hdmi processors going dead,  and in some cases you could not order them as a part or pcb's

i hope its not the case  but ....   

You have to follow signals paths with scope etc ... inject a video signal and see where it goes before dying


or

https://forum.polkaudio.com/discussion/134365/elite-sc-57-hdmi-board-gone

[zzattack]

Spent some (well, some²) more time on this device and reached partial success. Although the repair has become a time sink far exceeding any reasonable investment, it's turned into a personal vendetta to get it to work completely now.

I've replaced each of the 5 most relevant ic's, those being 2x HDMI transmitters (IC1602, IC1603: Sil9136CTU), 1x HDMI receiver (IC903, Sil9233), 1x HDMI switch (IC905, Sil9387) and the main CPU (IC101, some mid-size BGA). Swaps were performed in that order.

 * After replacing HDMI transmitters, internal menus started working (i.e. produce HDMI output), but passthrough of hooked up inputs did not work
 * While replacing the HDMI receiver IC903, I bridged two legs of a resistor network, which joined the RXHSYNC and RXVSYNC lines. This was the cause of the issue for which I opened the thread.
 * Clearing this bridge solved the mentioned 'HDCP error'. Now passthrough on inputs 5-7 works fine, but 1-4 give no output or HDMI signal LED on the AVR.

Looking at the video block diagram on pages 20-21 of the service manual shows that inputs 1-4 are routed through HDMI switch IC905; the active input is routed to IC903.
Naturally, the HDMI switch IC905 becomes suspect. I've replaced it twice with aliexpress "genuine new" replacements, which both times killed 'nearly' all video output. Internal menus would no longer display properly, appearing to lose sync or miss color channels. Sometimes it'd work for a few seconds up to a minute. I'm unsure how a bad IC905 can be involved with this. Removing IC905 entirely in fact results in the same issue. My best guess is the main CPU repeatedly reinitializes all of the HDMI ICs if it detects anything amiss.

Next I used donor parts from another AVR where I first verified that the HDMI functionality was 100% working as should. Replacing IC905 restored the internal menus and unrelated inputs 5-7, but inputs 1-4 still don't work. Eventually I decided on replacing the (aliexpress) HDMI receiver with the known working part from the donor, which made no difference either. After verifying integrity of signals between IC903 and IC905, i.e. not missing any passives and traces, and verifying presence of all input voltages for both ICs, I moved over the main CPU from the working donor. This again made no difference at all. In the picture below I've highlighted all areas which I've manually verified to be in order (i.e. voltages/resistance as expected, no missing passives, traces connected on both ends).




I've now exhausted my bag of ideas and am unsure what more I could check or where my issue could lie. One final idea would be to sniff on the I2C bus on HDSCL/HDSCA which I suspect to be driven by the main CPU, but I would have no idea how to interpret any potential data on there. I have verified trace continuity of this bus between IC903 and IC905 so I have no reason to suspect any issue on this bus.

Any suggestions for additional signals to trace or ICs to swap are welcomed.


For completeness, service manual is here, pretty large PDF: https://files.zzattack.org/temp/RRV4325_SC-68.pdf

[zzattack]

Another thought crossed my mind: it seems the Sil9387 switch is not very invasive on the signals. Should I be able to hook up a display directly to the output of the switch? That would conclusively determine that the issue isn't with the switch, but more likely with the either the reception in the HDMI receiver IC or the configuration of this receiver IC. It will be a tricky hookup, does it have any chance of success?

[zzattack]

To hypothesize, I wired up the setup as imaged below:



The idea being that the HDMI splitter
 1) strips the HDCP thereby eliminating any possible encryption errors
 2) has indicator LEDs on the outputs which light up when a sink is connected -- they only light up when the corresponding output is actually made active on the AVR
     ---> This allowed me to confirm that the Sil9387 indeed negotiates with the selected input on HDMI 1-3. Comms with the main CPU must be good then.

 3) provides a means where I can easily provide an input source to the HDMI switch Sil9387, while simultaneously force-feeding the same video signal into the Sil9233.

Now, 3) seems very much like a 'random idea', but there's some rationale behind it:
 * the board has no traces for the SDA/SCL between Sil9387 and Sil9233 channel -- apparently the negotiation is only performed on the Sil9387 then, and perhaps the main CPU configures the Sil9233 to a compatible mode?
 * I intended on lifting the output pins on the Sil9387 so they would not interfere with the secondary output from the external splitter -- I forgot to do so before initially hooking it up as depicted above. That means both the Sil9387 and the external splitter were simultaneously driving the input to the Sil9233. Surely that's not supposed to provide any reasonable kind of diagnostic... Wrong! This results in video output.


So, my conclusions/confirmations for today are:
 - communication and power to Sil9387 appear fine
 - somehow the DDC info for the inputs through Sil9387 are properly exchanged with Sil9233, possibly through main CPU
 - when AVR is set to HDMI1-3, Sil9233 is properly configured to display input coming from the Sil9387
 - despite all this, the Sil9387 does NOT route its selected into its output to the Sil9233

Given all of this I must address the possibility that the Sil9387 is bad after all. I'm hesitant to draw this conclusion since I've replaced it multiple times by now.

Final ramblings:
 - Perhaps the Sil9387 ICs cannot sustain the thermal stress I placed on it. That would explain why multiple chips might have failed.
 - Removing it (initially) took a LOT of heat, much more than (say) an older BGA laptop GPU.
 - Having learned this, for my donors, I managed to remove them with slightly lower temperature by first mixing the QFP legs with a lot of fresh leaded solder, but still needed about 300°C to remove it (on a BGA rework station with proper preheating).
 - I can (could) verify the Sil9387 is still good by re-transplanting it onto its donor, but then I also need a new Sil9233 for that. They're in the mail (aliexpress again, different sellers). Not my preferred continuation.

The only other explanation is that the Sil9387 is somehow properly configured to negotiate its input, but either refuses or fails to be convinced to carry the signal through onto its output.