All I know about the Philips QFU mainboard problems

I have had my share of experiments and frustration with the Philips QFU mainboards from the xxx7 (QFU 1.1, 2.1 for some 6xx7) and xxx8 (QFU 1.2) series. I am going to continuously collect everything I know here in this post.

General architecture

The main Fusion CPU is actually two CPUs in one plus the Trident graphics device and therefore also called a system on a chip (SOC):

• The boot processor, which runs on 3.3v standby voltage. It reads its bootscript (the standby software) from the SPI EEPROM 7CT3, which is a M25P05 512kBit type.

• The main processor requires the 12V supply to be up and is fed by a number of DCDC converters. Its software is stored in the 8 GBit NAND flash rom. This flash does not only contain the main software (the linux file system with the apps on it), but also the model-specific security keys and the MAC address. This is why a binary image from one board might not work properly on another.
• There are two types of Fusion. The 120 and the 240. The exact difference I do not know. The 240 seems to be used in the higher models (7xxx and up).

The original sins

Undersized cooling

Philips dramatically undersized the cooling of the Fusion processor. They stuffed too many functions onto the chip and did not take care of sufficient cooling. The Fusion 240 seem to have a larger heat sink with proper spring-loaded mounting posts, which stick through the board. The 120ies have sloppy small sinks glued with a heat pad. I am not 100% sure about the sink sizes though, so far I've seen larger sinks on QFU1.1 mainly.

The back cover is so close to the heat sink, it almost sits on it. The engineers thought that a little convection cooling would do the job. Absolutely ridiculous. 

Cases have been reported where the sink fell off by itself because the pad glue failed. This indicates that there were temperatures of at least 80°C. When I remove the sinks I use a heat gun and gloves. The pad glue gives up and goes soft at about 80°.

In a proper PC architecture, such a chip would sport a large cooler with a fan on it.

The larger sinks seem to have the side effect of grilling the SPI boot EEPROM, which might lose its first data block and render the TV dead. More about that further down.

Warped QFU1.1 boards

The boards of the QFU1.1 series are so thin that they warp around the CPU. Under the CPU the board is flat and around the CPU it bends up and down.

This makes any attempt of reflowing or reballing futile. The chip will never sit flat. I recently reflowed a QFU1.1. When the chip settled, it touched the board at one corner and lifted up a little on the opposite corner. Of course this was a total failure and the board is toast now.

Sometimes during my reflow experiments, the chip even jumped off the board with a snap due to the tension.

The QFU2.1 are better in that respect, but they also tend not to be flat around the CPU.

Known failures

• TV does not start and blinks 2x red after a couple of minutes. This is the classic. The 2x blink is reported by the boot processor, which observed that the main processor failed to boot. CPU or NAND failure.
• TV randomly crashes after some time. CPU failure.
• TV produces distorted image with striping or noise. Image freezes. CPU failure.
• TV does nothing at all, not even blink. This can be a case of a corrupted SPI EEPROM.

The infamous 2x blinks - the "K" fault

I've seen many of those. When reading the log through the UART service port (see this post how to do that), the log abruptly ends with the letter K. I described this fault in this post.

My suspicion is that the CPU loses communication with the NAND flash. This makes the diagnose, whether the CPU or the NAND is to blame, difficult. In most cases though, the CPU is the culprit.

The only feasible attempt for a "fix" (hack)

The Fusion CPU needs to be heated up to 180°C max in a controlled fashion. The solder must not melt! As explained above, this can ruin the board due to the warping and tension under the CPU. 

I use an IR6500 reflow workstation for it, which allows me to use a controlled temperature curve. 

The next best method is a pre-heated oven and a digital thermometer with a type K remote sensor, which can be attached to the CPU. Those devices only cost a few bucks. This allows for proper monitoring of the temperature since ovens made for households are not precise. 

With any method, cover the plastic parts and electrolytic capacitors in tin foil. It is not strictly necessary to cover the other parts. They can handle it. The temperature is kept below the solder melting point, therefore there is no danger of dropping parts from the bottom side. With the rework station I only use a square tin foil mask around the CPU, just enough to cover the CI-slot.

The solder balls under the CPU do not fully melt until 235° is reached on the top of the CPU. This chip is thick and needs plenty of heating to come off the board.

I would rate the success rate of the baking technique at 50:50. It is like a coin toss. I have had a few successes in a row, but also losing streaks.

The mysterious NAND flash

I tried a to swap the NAND a few times and never succeeded. In this post I documented the tools I use.

In a recent case I copied the original NAND image onto a new chip, soldered it in, and the UART log was gone. After putting back the original NAND, the log still was silent. Something must have happened in between the two actions and I never found out what. The NANDs behaved perfectly fine on the programmer tool and the verification against the image file succeeded. I have not damaged them. My suspicion is that the heat from the bottom preheater had triggered a defect in the CPU or on the board, which brings us back to square one.

I experienced this twice. Only worked on the NAND, and yet, something else broke down. The UART lines are fed directly from the CPU. There is nothing in between. Thus, if nothing is put out there, the CPU is to blame. The service manual says that if there is no log, a communication problem with the NAND could be the reason. I don't understand that, why would the boot processor require the NAND? However, it fits the observation.

There were reports that the NAND image from an identical QFU platform can work. I cannot confirm that as I even failed with the image from the same device. Also, the board-specific parameters and security keys will not match. You might not have network access, and the CI slot might not work after that. The service manuals describe in detail how to reconfigure a generic service board. The necessary tools and software are not available to normal people.

All that brings me to the conclusion that tampering with the NAND is also futile and not worth the time.

The boot SPI EEPROM

This memory chip holds the boot software for the boot (stand-by) processor.

I had only one case where the boot SPI EEPROM was corrupted. I've programmed a few of those for other people. It seems that this is more common in the QFU1.1 boards where the heat sink is covering the chip. It probably doesn't take too much heat, either.

The fix is very easy if you have a programmer yourself or know someone who has. Go to this link for a collection of my tested boot images.