At pickup the seller told me that the TV had been fixed during warranty with the same symptoms. The mainboard was the culprit then. Uh oh...
When I plugged it in, the standby LED did not light up. Standby voltage was present. The LED is controlled by the main processor (the standby processor section). The only voltage the stdby proc. takes in is the 3.3V standby. Nothing else. The LEDs are fed with the same voltage.
I studied the service manual thoroughly and the only conclusion was that the processor was in trouble. I ran a reflow session in the oven. Did not help.
In the Iwenzo repair forum, I got the hint to reprogram the standby software flash ROM. For that you need two things:
- The software binary for the QFU1.1 platform SPI boot EEPROM. Version 77.02.
- An EEPROM programmer.
I also purchased an EEPROM programming device called SkyPro USB Programmer. It is made by Coright. The software installed flawlessly on Win10. I had to desolder the Flash ROM 7CT3 and solder it on an adapter board, which then went into the programmer's socket.
The chip sits under the upper right corner of the white heatsink. The sink has to be removed carefully. It is mounted with two spring bolts, which are easy to release, and an adhesive foil. The foil does not survive the process.
I tried a test clip from Aliexpress first directly on the board. This was like lottery. The clip did not attach properly and I got only nonsense results.
The software then identified the Flash as 25P10 (128k) instead of a 25MP05 (64k), which is listed in the service manual.
Now, the hardest problem was to find the right software as there are a number of versions floating around in the net. The QFU1.1 has two variants. One for Fusion 67.0.0 and one for Fusion 77.02.08. This device needs the 77 version.
The 77.04.08 is QFU 1.2 and will not fit. It is used in the xxx8 series, not the xxx7.
To add to the confusion, 77.02.08 is also supposed to work for QFU 2.1. This is only used in the 6007 model, however.
This is the software that worked for me: DOWNLOAD
A peek into the binary files
The first diff shows the good file to the left, which finally revived the set, and the scrambled one to the right, which I read from the EEPROM initially. You see that the first block is wiped out with garbage. There were more garbled blocks further up the address space.
The second diff shows the Fusion 77 to the left and the Fusion 67 to the right. If you have a file at hand and like to investigate which version it is, take a HEX viewer and study the first block.
Notes
I first did not realize that the TV was actually fixed because I didn't insert the flat cable to the TCON properly. It looked totally fine, yet it wasn't sitting right. The sockets on the mainboard have a locking mechanism. You need to push the two black knobs down. I failed to do that and broke off the locking nose on the cable. The cable then does not sit very well anymore.
The TV was stuck in a boot loop because of the cable. The log displayed weird errors about the DVB-S tuner. In hindsight, it must have been trouble with the I2S bus.
I stumbled over the solution while testing another board where I made the same mistake with the cable again! This time I caught it rebooting immediately after I had touched the cable.
I once destroyed a not properly seated cable. A trace went up in smoke. Be very careful with those.
Don't forget to plug all wire harnesses into the mainboard. If the WLAN is missing, you will also get a loop.
So what is going on with those QFU chassis?
A number of devices with similar symptoms are mentioned in repair forums and sold on eBay/classifieds. What's going on here? How can an EEPROM, which is otherwise fully functional, lose blocks of its memory? What I know is that the processor gets really hot. I measured 57° celsius at 21° room temperature with an open back cover. Now extrapolate that to 30° and closed cover. I recon it will be 70° or more. Does the EEPROM get grilled? I don't know.
