Samsung Odyssey G9 OLED (S49CG934SUXEN) - No picture, no backlight, no LED

[platinum95]

Hi all,

I picked up an as-is monitor for repair, monitor has no visible damage but is also (mostly) unresponsive. When plugged in, the power LED remains off, monitor is not detected by PC over HDMI (or mini HDMI), and the buttons have no effect. The built-in USB hub is detected by a PC though, so there is at least some life in the unit.

I've popped the back case off, there are 3 major boards inside: Main display board (BN41-03181A), secondary/sub-main board (BN41-03182A), and T-CON board (BN96-56364B). This variant of the G9 display doesn't have an internal power supply like most G9s, and instead takes power from an external 20V 11A power brick.

I've checked the fuses on the v-supply input stages of each of the 3 boards, and they all seem fine.

When powered on, the secondary board has some faint coil whine, so I can tell it's getting power. DMM confirmed the 20V supply is delivered to it. This secondary board has a boost converter for the T-CON v-supply, and is DMM confirms it's outputting the 32V that is sent to the T-CON.

There's a very faint whine from the main board as well. The main SoC on the board gets hot when plugged in, so it's evidently also getting power. There's a "KEY-IN1" test point on this board that comes from the power switch on the secondary board. This is at 3.3v when powered on, and drops to 0v when the button is pressed. So the ON signal is at least making it to the main board.

Anyone have any thoughts on where to go from here? I have a scope so I can take some more detailed measurements if required. I should also have some hardware capable of reading the SPI flash if required, though I'll need some pointers on which one exactly needs to be read.
I'm also fine with replacing an entire board if I can find a suitable replacement, so if it's possible to work out which board the fault is on that may be enough.

Thanks!

[platinum95]

I've dumped the 2 16MB Winbond flash chips on the bottom of the main board. The left-hand one is erased and contains only 0xFF repeating. The rightmost contains what looks like valid data (found some ascii strings amongst general random binary).

Does anyone know what I should expect from these 2 chips? Or how I might verify if one/both has corrupted?

[platinum95]

Tried a replacement mainboard (BN41-03181A/BN94-18231Z), same issue persists. It's from a trusted seller, so unlikely (though not impossible) that the replacement has the same fault as the original.
I'll probe around some of the test points to see if I can narrow down the fault.

[platinum95]

I found a UART Tx pin on the main board that seems to be attached to the main SoC, and is sending out a system log. I've attached a dump of the startup sequence, but the main takeaway is that startup is stalling on a repeating log output of `SecDrvTcon_ReadPowerOnStatus: 00 00 00 00`.
This points towards the power management on the TCON board being at fault (or something in that general direction). I did find that the 'PMIC_FB33_ALERT' test point was high, though I'm not sure if this is alert asserts on high or low level. The 3.3v test point reads 3.3v.
I have a thermal scope that I used for checking for bad/shorted components, it's intended for wildlife use but is somewhat usable here if you stand far enough back to get into the minimum focus plane. (I do also have an iPhone FLIR attachment, but they've pulled the app version that runs on my old iPhone and have set the min iOS version beyond what I have.... thanks FLIR).
I've attached a picture taken from the scope with power applied, plus a reference picture of the board. I can't see any obvious bad components, but is it just me or is it suspicious that the 2 display processors not symmetrically hot? I wonder is there an internal fault in one of them which is triggering the overcurrent protection from the PMIC?

[lotas]

If the problem is in the panel, you can test it by installing feedback jumpers on the T-CON and disconnecting the cables going to the panel one by one (disconnect one cable, turn on the monitor and observe the monitor's behavior, then reconnect the first cable, disconnect the second and also check).

[platinum95]

Same issue, UART log hangs on a repeating `SecDrvTcon_ReadPowerOnStatus: 00 00 00 00`. I'll keep an eye out for a replacement T-CON board, and in the meantime continue trying to root-cause it in case it's an easily obtained component that needs replacing.

[platinum95]

Found a UART Tx test point for the 2 display processors on the T-CON board. They're both outputting the same thing, and boot-looping with the following output about once per second.
```
_____ BTA0BL1 Core[0] EMMC_____
ERROR : FW#1_CORE0 magickey error(0x0)
BL1 EMMC FW#2 core0,1
_________________ BTA0FW DQHD(VD) _________________
Keil 5060183, Build(Apr 23 2023 14:06:03)
Multi Inferface Master SPI Init
FW 1, CFG/MS 1
Boot GPIO CNT Over
system reset!
```

[tom66]

I suspect bad firmware for the T-con main processor based on that.

[platinum95]

That was my initial impression too, but it seems odd that both processors would have corrupted firmware in the exact same way since they each have a dedicated eMMC, unless there was an interrupted update procedure where both eMMCs were being flashed simultaneously. It does also fallback successfully to FW#2, so my theory here is that FW#1 is something like a factory calibration FW, and is wiped prior to shipping allowing the processor to fallback to the consumer firmware in slot 2 on boot.

[tom66]

It could be that only one is corrupted, but the communication between the processors is needed to proceed.

[platinum95]

Yeah that's true. Do you know where I could find the firmware image for the T-con? I'd need to source an eMMC flasher in the meantime as well.

[tom66]

Unfortunately not. Best bet is a second hand T-con if you can get hold of one. A complication for OLEDs is the T-con eMMC often stores calibration data; without this the panel image may be poor. In some cases, the calibration data is backed up to the main board, and the main board can synchronise it to the T-con through a procedure described in the service manual. In other cases, you have to extract calibration data somehow, which may be impossible, meaning you also need to replace the panel.. obviously uneconomical for many.

[platinum95]

I'll keep an eye out for a replacement T-CON, seems they're generally low availability, at least at non-ludicrous prices.
The service manual is another challenge to get, seems they're also like unobtanium.
I had a look for an authorised Samsung repair shop as well, since they'd have access to the diagnostic flows and service manuals. Seems the only one in my country closed last year 🙄

[platinum95]

Spoke too soon, got my hands on the service manual, but it's not very helpful unfortunately. The troubleshooting step is essentially "issue on T-Con?: Replace T-Con", no more detail than that.

[tom66]

Hopefully that means the T-con board synchronises from the main board then. But unfortunately I could not say for sure.

[platinum95]

I've found what I believe are firmware image(s) for the T-CON board. Extracting the strings from the file show what look like string-literal log statements that closely resemble the style/content of the statements I was getting from the UART output. I can try flashing the EEPROMs with what I've found, but I've a number of issues to work out first:
1. How is the firmware file packaged? 1-to-1 writing of the file to the eMMC or does it need to be unpacked/offset first?
2. There are 2 firmware files, not sure if there's 1 for each of the display processors on the T-CON or if it's model/region variants.
3. Need to work out the pinout of the eMMC pads on the board, since they're not labelled in the silkscreen.
4. Need to get a compatible eMMC reader/writer.

I should probably start with the reader/working out the eMMC pinout to get a read of what's currently on the EEPROM, to determine if flashing is even necessary.

[tom66]

eMMC chips generally have a consistent pin out. eMMC is basically an SD card that is in soldered down form, so you can usually read them by modifying an SD card reader/writer, and buy these readers quite inexpensively. Some earlier eMMCs did have variable pinouts, the JEDEC organisation standardised them so there are now only a few. The vast majority of the balls on the underside of the chip are unused - this seems a bit odd but the chip needs these for mechanical stability rather than data. These devices can also be read out using a 1-bit, 4-bit or 8-bit interface.



(Be sure to look up the part number to determine if the chip is 153 ball or some other configuration)

My suggestion would be that you desolder the chips being careful to not damage the balls and then you get an eMMC reader which is solderless. You can read the eMMC out and determine by inspection if the data is constructed the same. Unlike NAND, the eMMC contains the flash controller, so it's possible to read them out without knowing anything about how they function, not even capacity.

Buy new eMMC chips of similar capacity and part number to reflash.

I have not used this myself, but this is the type of device you would use:
https://www.ebay.co.uk/itm/188115627789

[benberry24]

(Employee of account owner posting) Apologies if this is improper. I have one of these we wound up with (S49CG954SN with BN96-56364B). Cust came in with no pic. Quick info online pointed to thermistor. Took apart and realized it's not the board with the apparent thermistor that is a quick easy one. Couldn't find any useful info. I ordered a replacement t-con board and crossed my fingers. It works again, but has the gray bars and subpar quality as is stated all over. We ended up giving her some money for it so she could just replace it (and hopefully us be able to fix it).

All that to say, I have 2 t-con boards, one working (but not correct) and one not (but has the correct programming).
I'm a novice at best when it comes to soldering, but I can solder wires to pads. I have a UART reader for PS5 if that will work. I have a DMM. I can try and pull data from these boards for you to compare (if you advise me where to look). Maybe along the way, a solution can be found for me to write the proper programming data to mine (or fix the OG board). The owner does microsoldering so if I have to have him do something, he might be able to. EDIT:: Bossman has a thermal cam too FWIW

🤷♂️
Ted

[platinum95]

Bit of an update here, tl;dr is I managed to get the screen running again on the original T-CON, and then at the last step before a permanent fix managed to fry that original T-CON with a loose debug wire 🙄

The T-CON has ARM SWD breakout pads for each of the SoCs. I was able to hook up a Pi Pico Debug Probe to each of these and get it hooked up via OpenOCD. From there I could halt execution within the reset loop, and pulled the RAM contents out into a binary dump. In the meantime, I also found a set of firmware update files for a similar Samsung screen that had some extra files versus other firmware releases. Assumed these were for the TCON, and grepping out the strings within shows solid matches with the debug statements I was seeing from the T-CON SoC's UART output, so that was correct.

I was able to get both into & analysed with Ghidra. Full disclosure, I threw an AI at it at this point through an MCP bridge in Ghidra to get through some of the tedium of cross-references raw pointer values in the firmware dumps. Here's what I was able to work out:
- Both SoCs have near-identical firmware, and near-identical hardware, so I can just state things for one and it generally applies to the other.
- The SoC has a built-in bootloader ("_____ BTA0BL1 Core[0] EMMC_____" in the UART log).
- The eMMC has 2 firmware images on it.
- Bootloader tries loading FW1, checks 'magic key' at offset 0x0, and fails to FW2 if Magic key check fails ("ERROR : FW#1_CORE0 magickey error(0x0), BL1 EMMC FW#2 core0,1" in UART).
- FW2 does some init stuff, then polls GPIO5 a number of times awaiting a LOW state. If state is not reached, it resets ("Boot GPIO CNT Over, system reset!" in UART).
- Notably, FW1 does not wait on GPIO 5.
- Also notably, patching the running firmware (FW2) to skip checking GPIO5 allows the screen to start up properly.
- Also notably, the newer firmware update for the T-CON I found first sets GPIO20 HIGH before checking GPIO 5. It's possible this is a bug in FW2, where GPIO 20 must be set HIGH for whatever drives GPIO 5 to respond. When FW2 is patched, GPIO 5 ends up LOW in the booted state which suggests that whatever is driving it is working correctly, but the ordering of the handshake in the FW is wrong.
- Another big finding is that many of the error-state handlers in FW1 intentionally blank the first 512 bytes of the FW1 in the eMMC. This is why we the magic key check is failing and why we end up in FW2. It's a permanent failover into FW2.

Anyway with all that info I was able to get some OpenOCD tcl scripts together with some helper functions that call into known functions within the firmware to do things like interface with the eMMC. This was I was able to grab some dumps from the eMMC without directly interfacing with it. Only grabbed the first ~10MB since it was very slow, but this covered both FW1 and FW2. I also had a helper 'patch' script which automatically applied the "skip checking GPIO 5" patch to both running SoCs, which let me quickly get the screen booted up for testing. It all worked fine when booted, was able to take HDMI signal and displayed it fine, OSD was fine etc..

Unfortunately, when I was working towards a permanent fix of installing that newer firmware, I managed to knock one of the SWD debug wires and fried the secondary SoC on the board.

I got my hands on a replacement TCON from Aliexpress, which had the exact same firmware builds as my original. This time, I tried copying the first 512 bytes from FW2 into FW1's slot on the eMMC to restore the magic key and FW header. This actually worked as a permanent fix, and the patch wasn't needed anymore - at least until it hit one of those errors states I was talking about earlier, where it again wiped the first 512 bytes and started failing in FW2 again.

Either way, with the screen booted in the replacement TCON it was clear I was missing the calibration data as I had similar inconsistent bars as Ted mentioned. I'm currently working on finding out where this calibration data lives, fairly certain its on the eMMC somewhere outside of the 10MB I dumped. I found a panel ID string ~80MB in, so it's likely the calibration data is adjacent. I'll continue digging on the still-working SoCs and should be able to pull whatever data off those fairly easily. For the fried SoC, I'll likely have to interface with its eMMC directly which will be more difficult (but all part of the fun 😄)

[platinum95]

benberry24 hopefully there's some useful info in that last post for your case. I think the next step is to work out the pinout of the eMMC breakout pads on the T-CON board to interface an external reader/writer with it, and then work out the calibration data offset within the eMMC. That way in future anyone doing a T-CON swap can just copy-paste the calibration data from one board to the other.