[SOLVED] This doesn't look fixable to me... - Page 1
Forum section: electronics / projects

author: gnif
author_rank: Unknown
timestamp: November 24, 2017, 03:56:39 am
content: Anyone care to speculate as to the fault? My guess is faulty RAM but there doesn't seem to be any DDR modules on the PCB, just a Samsung ASIC. Monitor has already been isolated as the fault, performs the same on any input & cableSymptoms:Colors....OSD has switched to DutchOSD menu never shows, only contrast/brightness quick access screen.And yes, that is snow on a digital display.... go figure.I have two more of these screens, swapping the PCB into them proves it's a PCB problem, not a panel issue.For reference it is a Samsung S24C650BW

author: jbb
author_rank: Super Contributor
timestamp: November 24, 2017, 04:48:55 am
content: The 'analog style' noise is odd...It's a total guess, but maybe there's a loose connection (cracked solder joint?) on the board? That might result in a bad connection that sort of works (maybe capacitive coupling between adjacent signals) with some susceptibility to noise.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 24, 2017, 05:02:20 am
content: Tin whisker shorting a pair of data lines together?Anyone's guess without a lot of poking and inspecting...Tim

author: gnif
author_rank: Unknown
timestamp: November 24, 2017, 05:08:25 am
content: Fixed! It was a faulty I2C EEPROM. There are three on the board, two are clearly for monitor EDID information (VGA & DVI), the third is configuration storage. On the DSO could see that the SCK line was not toggling, so I lifted the eeprom off the board and it started to clock... the EEPROM had failed. I replaced it with a scavenged part and blanked it, which didn't fix the problem, so I flashed it with all zeros... fixed.Further messing around I figured out why it corrupted the output, three signed 8 bit bytes control the R, G & B intensity values, where 0x64 is the highest configurable via the OSD interface, but since the I2C wasn't reading it was returning 0xFF... welcome to integer overflow city. It also explains the faulty menu as it's configurable X/Y position was also out of bounds.Interestingly I can also change the service information too (hours on, etc).Code:struct serviceInfo // @ 0x0{char monitorOnTime;char panelOnTime;char unknown; // might be a GUID or serial, no way to know without a working eeprom to compare with.char powerCycleCount;}struct menuPosition // @ 0x47{uint8_t x, y; //maximum value = 0x64}The serviceInfo values are not integers but strings and only 6 bytes are shown in the OSD but all 8 are used. They use some non standard character map (not ASCII):Code:Ord Character0x00 00x01 10x02 20x03 3...0x09 90x0A "...0x41 pMore can be discovered through trial and error, comparing dumps. One undocumented feature I have noted when just setting the entire eeprom to an arbitrary value (0x4) is a soft fade in rather then a sharp turn on when waking up, it would be nice to find the byte that turns this on.I don't have time at the moment but later I will poke at it a bit more and see what else lurks in this EEPROM

author: jaycee
author_rank: Regular Contributor
timestamp: November 25, 2017, 10:48:55 am
content: Good save ! I would have said that was internal display buffer RAM having failed just by looking at it.