Solved: LG 27UL500w LCD Monitor SPI Flash corruppted - Flash dump required - Page 1
Forum section: electronics / repair

author: DL4JY
author_rank: Regular Contributor
timestamp: April 05, 2024, 06:00:18 pm
content: Hello,I have a LG 27UL500w 4k 27" Monitor - three years old. It stopped working and the buzzer is giving some kind of humming noise.It seems that the SPI Flash got corruppted. The problem is now how get the original content of the flash IC . I am probably able to write the flash via HDMI I2C - if not, definitely with a programmer.Can somebody help out, please ?many thanksJuergen

author: DL4JY
author_rank: Regular Contributor
timestamp: April 08, 2024, 06:10:19 pm
content: Hello ladies & gentlemen, Hello Daveto elaborate a bit on the VGA,DVI,HDMI I2C Interface.Especially with Realtek/LG in view. And how to get a dump of the SPI Flash.The Video busses have a dedicated communication line für I2c - SDA & SCL.Through this you are in a position to access the internal SPI flash (Gigadevice 25q32) with special commands through the Realtek integrated circuit (here: RTD2595) . This is true for read and write.You can acess the internal Flash - as said - via HDMI. I used an Raspberry 3+ (RPI) to do this.The software required is minimal - once you found it. :-)Seehttps://github.com/floppes/RTD266xFlashas reference.This is what I have done to virgin RPI installation:steps in detail required:sudo nano /boot/config.txtadd there:dtparam=i2c2_iknowwhatimdoingdtoverlay=vc4-kms-v3dCtrl-o to write the config back to SD.check that you can see your monitor via I2C.i2cdetect -y 2standard is I2Cbus No. 2 for the HDMI monitor on the RPI.now get the python script to read/write & erase the SPI flash IC over HDMI.git clonehttps://github.com/floppes/RTD266xFlash.gitcd RTD266xFlash/RTD266xPyVoila ready:this reads the 25q32 which has 256 x 16384 banks & 32 MBit = 4 Mbyte.takes ca. 15 minutes to runpython rtd266x_flash.py -i 2 -r 4194304 -f LGdump.binAfter this you have on the SD-Card of the RPI the dumped firmware of your LG Monitor.Save it - sometimes SPI can get bad. I had that after a master/slave power socket started to oscillate with ca. 10Hz.Upload of the file can be done viapython rtd266x_flash.py -i 2 -w -f LGdump.binThis is all and not from me - just collected.BTW, if somebody has after this procedure accidentally a usable LG27UL500W dump for me ... ?Vielen Dank& best regards,Juergen

author: fzabkar
author_rank: Super Contributor
timestamp: April 09, 2024, 06:07:33 pm
content: I can't help, but can you upload your flash dump? There may be a checksum which validates the contents.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 09, 2024, 06:53:12 pm
content: Some dumps I got fromhere.It seem to be a common fault, it might work after flashing, but better replace the flash IC!

author: DL4JY
author_rank: Regular Contributor
timestamp: April 09, 2024, 07:47:14 pm
content: Many thanks,actually the dump all have different checksums and they are not accepted by the RPI Flasher.This reminds me a bit of my corruppted Flash. There I got with every read procedure another checksum.I will look into more details tomorrow.best regards,Juergen

author: DL4JY
author_rank: Regular Contributor
timestamp: April 09, 2024, 07:53:31 pm
content: Yes, I had to replace the flash, as the original is not programable anymore.I tested with an 27ul650 - but there is something different, now it beeps after power on and does as if it is an monitor but shows no picture.thanks again,Juergen

author: fzabkar
author_rank: Super Contributor
timestamp: April 09, 2024, 08:25:45 pm
content: I merged those 4 bad dumps by bitwise AND-ing their contents. The assumption is that bad bits flip from 0 to 1 (1 = erased state). Perhaps you'll get lucky.

author: fzabkar
author_rank: Super Contributor
timestamp: April 09, 2024, 08:43:59 pm
content: Quote from: DL4JY on April 09, 2024, 07:47:14 pmDid you save those reads? If so, then it may be possible to build a "hybrid" flash image by combining all your dumps.As for the RPI flasher (Raspberry PI?), I can't see why it would refuse to accept your dumps. The RPI has no way of knowing whether the checksum is wrong, or whether there is any checksum at all.

author: DL4JY
author_rank: Regular Contributor
timestamp: April 09, 2024, 09:05:04 pm
content: thanks. I will try tomorrow. The point is, I am using the Python script to read and write. This makes a CRC check before upload on each block. My incircuit programmer can't programm in the videoboard. and Desoldering plus soldering again is a bit of work. But finally I may have to do it again.cherio

author: fzabkar
author_rank: Super Contributor
timestamp: April 09, 2024, 09:30:57 pm
content: Those other dumps report differences in a small area of the SPI flash. If your flash has problems in a different area, and if the contents are from the same firmware version, then it may be possible to build a functional Frankenstein.If you upload your 27ul650 dump, that may be a useful point of reference, at least for calculating the checksum, if it exists.Code:C:\>fc /b dumpmerg.bin dump.binComparing files dumpmerg.bin and DUMP.BIN003FC0D7: 01 05003FC0E7: 00 40003FF865: A2 A3C:\>fc /b dumpmerg.bin dump1.binComparing files dumpmerg.bin and DUMP1.BIN003FC034: 32 B2003FC062: 64 6C003FC0C3: 00 04003FC0D1: 00 20003FC0D7: 01 05003FC0E7: 00 40003FC833: F3 FB003FF095: 32 72003FF0E2: 02 12003FF177: 64 74003FF20A: 00 08003FF253: 32 36003FF260: 32 B2C:\>fc /b dumpmerg.bin dump2.binComparing files dumpmerg.bin and DUMP2.BIN003FC062: 64 6C003FC0A9: 01 81003FC0C3: 00 04003FC0E7: 00 40003FF260: 32 B2C:\>fc /b dumpmerg.bin dump3.binComparing files dumpmerg.bin and DUMP3.BIN003FC03F: 32 3A003FC041: 32 33003FF20A: 00 08003FF260: 32 B2I notice that the range from 0 to 0x6350 has the same content as 0x10000 - 0x16350, 0x20000 - 0x26350 ... 0x190000 - 0x196350. That is, this same large block of data is repeated 26 times. This seems very wasteful (0x6351 x 26 = 661050 bytes).The last 0x100 bytes of every 0x10000-byte block appear to be filled with 0xFF (up to offset 0x200000).The range 0x3FC000 - 0x3FC0FF contains a block of data, possibly configuration information (0x64 = 100, 0x32 = 50). Very similar, possibly identical, blocks occur at 0x3FF000 - 0x3FF0FF, 0x3FF100 - 0x3FF1FF, 0x3F200 - 0x3FF2FF.Code:Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F003FC000 00 00 02 00 00 00 00 00 00 00 00 00 0C 0C 0C 0C003FC010 0C 0C 00 00 00 00 00 00 0D 0D 0D 0D 0D 0D 64 32003FC020 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FC030 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FC040 32 32 64 32 32 32 64 33 32 32 64 32 32 32 64 32003FC050 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FC060 32 32 64 32 32 32 46 46 23 64 64 64 23 1B 64 64003FC070 64 64 64 2D 32 32 3C E4 64 64 64 64 64 64 1B 64003FC080 64 64 64 64 46 46 46 46 46 32 32 32 02 03 03 02003FC090 32 32 46 64 41 32 01 01 01 01 01 01 17 17 18 37003FC0A0 17 17 00 00 00 00 00 00 00 01 00 00 00 32 80 80003FC0B0 80 03 03 0E 32 32 32 32 B2 32 32 32 32 32 32 32003FC0C0 32 32 32 00 01 00 00 01 01 03 03 03 03 00 0A 00003FC0D0 00 00 02 03 00 00 01 01 00 00 00 00 01 00 00 02003FC0E0 02 00 02 03 00 00 00 00 00 00 00 00 01 00 40 00003FC0F0 10 00 00 00 00 00 00 01 01 01 01 04 00 00 A9 74These areas are affected by bad bits. I suspect that the final 16-bit word in each block is some kind checksum.There is a also this 0x90-byte block which has similar copies (not intended to be identical) at 0x3FF800 - 0x3FF88F and 0x3FF890 - 03FF91F.Code:Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F003FC800 B6 41 96 B6 B8 AC BA B3 C1 B9 19 CB EE E2 F1 02003FC810 F0 E8 E9 41 D1 E0 F1 01 F0 E8 F1 07 F0 E5 ED F1003FC820 11 01 02 0C 0B F4 79 F3 CC F0 41 F4 70 F2 74 C2003FC830 0B F4 78 F3 CC F0 41 F4 6F F2 74 C2 0A F1 A5 A8003FC840 E3 E5 F0 41 F2 CA C2 09 F4 A3 CA F0 41 F5 7F F4003FC850 B8 10 F1 53 62 5A 60 F0 41 F5 C1 C9 F1 61 F6 38003FC860 F1 4E 00 FF 86 A2 FF 86 B4 FF 86 C3 FF 86 D4 FF003FC870 86 E8 FF 86 FB FF 87 07 FF 87 1C FF 87 2E FF 87003FC880 40 FF 87 50 FF 87 69 FF 87 7A FF 87 94 FF 59 74

author: amyk
author_rank: Super Contributor
timestamp: April 10, 2024, 01:47:26 am
content: I have read that sometimes heating bad flash can at least temporarily give a good read; this is in the context of NAND flash for mass storage, but maybe the same physical processes are responsible and could apply to your case.

author: DL4JY
author_rank: Regular Contributor
timestamp: April 10, 2024, 10:13:20 am
content: First of all, I want to thank you for the time invested.Unfortunately are all the files not passing the upload program's CRC check.However, I hope to have soon access to a 27UL500 - and be able to dump the flash with my Raspberry Pi (RPI) via the HDMI cable.Regarding the content of the files - it could be that not all of the memory is used - and that these dumps would work, even though the CRC is failing.For the time being, I will wait for the download and try then this to upload.best regards,Juergen

author: fzabkar
author_rank: Super Contributor
timestamp: April 10, 2024, 03:42:26 pm
content: If someone is looking for the datasheet ...https://datasheetspdf.com/pdf-down/R/T/D/RTD2525-Realtek.pdfQuoteEdit: Wrong chip (should be RTD2595, not RTD2525/2545/2555), but maybe the CRC algorithm is the same.

author: fzabkar
author_rank: Super Contributor
timestamp: April 10, 2024, 11:37:28 pm
content: Quote from: DL4JY on April 10, 2024, 10:13:20 amYes, I agree. I would be very keen to examine a working flash dump.ISTM that the firmware is incredibly stupid in the way that it wastes so much space. It would be much smarter to devote just a tiny bit of that wasted space to ECC bytes so that errors could be transparently corrected, and then those deteriorating blocks could be refreshed with the corrected data. Moreover, there is more than enough free space to back up the code regions, so I'm baffled as to why only half of the code has redundant copies. And why did the programmer choose to make 26 of these copies???It makes no sense to me at all.

author: modoran
author_rank: Regular Contributor
timestamp: April 11, 2024, 08:47:38 am
content: A very cheap ch341 can program 25Qxx just fine, why bother with something else via realtek cpu ? Maybe that's the problem.Also I am sure that are ways to program directly the spi flash if you wish with raspberry pi ( never tried tough ). Simpler ways are best. Of course, the flash chip must be desodered or use a new chip not mounted on the board.

author: fzabkar
author_rank: Super Contributor
timestamp: April 11, 2024, 07:06:33 pm
content: I have worked out the checksum for each of those data blocks.The last byte is always 0x74, so this must be a marker byte.The penultimate byte is an 8-bit checksum which is calculated by XOR-ing all the previous bytes.Code:Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F003FF200 00 00 02 00 00 00 00 00 00 00 00 00 0C 0C 0C 0C003FF210 0C 0C 00 00 00 00 00 00 0D 0D 0D 0D 0D 0D 64 32003FF220 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FF230 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FF240 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FF250 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32003FF260 32 32 64 32 32 32 46 46 23 64 64 64 23 1B 64 64003FF270 64 64 64 2D 32 32 3C 64 64 64 64 64 64 64 1B 64003FF280 64 64 64 64 46 46 46 46 46 32 32 32 02 03 03 02003FF290 32 32 46 64 41 32 01 01 01 01 01 01 17 17 18 17003FF2A0 17 17 00 00 00 00 00 00 00 01 00 00 00 32 80 80003FF2B0 80 03 03 0E 32 32 32 32 32 32 32 32 32 32 32 32003FF2C0 32 32 32 00 00 00 00 01 01 03 03 03 03 00 0A 00003FF2D0 00 00 02 03 00 00 01 01 00 00 00 00 01 00 00 02003FF2E0 00 02 02 03 00 00 00 00 00 00 00 00 01 00 00 00003FF2F0 11 00 00 00 00 00 00 01 01 01 01 04 FF FF A9 74^^ ==XOR8 checksum byte 0x74 = marker byteSeveral blocks in the merged dump still have errors. The table shows the expected and actual checksums of each block.Code:range act / exp------------- -----------3FC000_FE.bin - 0xC8 0xA9 bad3FC800_8E.bin - 0x59 0x59 good3FF000_FE.bin - 0xA3 0xA9 bad3FF100_FE.bin - 0xA8 0xA8 good3FF200_FE.bin - 0xA9 0xA9 good3FF800_8E.bin - 0x4B 0x59 bad3FF890_8E.bin - 0x37 0x37 goodI think these blocks can be repaired. Let me know if you would like me to try.I have attached my checksum calculator tool and my bitwise AND-ing tool. Both run inside a Windows DOS box.

author: fzabkar
author_rank: Super Contributor
timestamp: April 12, 2024, 08:28:06 pm
content: Quote from: fzabkar on April 11, 2024, 07:06:33 pmDone.

author: DL4JY
author_rank: Regular Contributor
timestamp: April 15, 2024, 02:43:04 pm
content: Hello,thanks for the support again. I flashed another SPI IC - and soldered it into the board, which switches on backlight, it beeps short - the LED is on , but no picture -I will give it another shot in a few days, but currently it is bothering me too much. :-)BTW, using the RPI was only because it is very handy to just go and read the flash just only with the HDMI cable. Non-destructive.Later I did it with desoldering and so on - but the PCB is not becoming better by every desoldering/soldering.saludos

author: fzabkar
author_rank: Super Contributor
timestamp: April 15, 2024, 02:50:14 pm
content: Quote from: DL4JY on April 15, 2024, 02:43:04 pmCould we see the dump? So far you haven't uploaded anything.

author: DL4JY
author_rank: Regular Contributor
timestamp: April 18, 2024, 07:22:18 am
content: I do see a kind of problem downloading via Python & HDMI from a good monitor - as I can not desolder the flash.Four times downloaded - for times a different CRC checksums :-(I am still investigating.bare with me.best regards,Jürgen

author: DL4JY
author_rank: Regular Contributor
timestamp: April 18, 2024, 03:08:40 pm
content: All,first of all I succeeded finally.The method was using an RPI , HDMI and lift write protect PIN3 of the flash and connect via pullup to 3.3V. So I was able to write back. The python script seems not to do the software write enable right.Why it didn't work with an external flasher and the same bin file - I don't know and I can't explain. Eventually the reason I decided to go for the lifted Pin of the IC was that I was tired of soldering/desoldering.However, what I found out, is that the monitor is writing always something back to the flash - in the upper region at 3ff000 and up.That is the reason why the CRC of the files is different every time you read it. Maybe a hour counter ?Thanks againcheerioJuergen

author: maopashi
author_rank: Newbie
timestamp: March 14, 2025, 11:50:46 am
content: Hello, I'm back on the subject a year later.@DL4JYQuote from: DL4JY on April 09, 2024, 07:53:31 pmI read that you might have a flash of the LG 27UL650. I'd be interested if you could share it with us.Thank you !