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

[tom66]

Pretty impressive work so far, good luck!

[Newb2000]

Very impressive indeed, im actually in a situation with the exact same. coil whine, no led, no display.
In my case i had a second monitor what i just tried is switching the motherboards, display still wont turn on.
The display on the working monitor turns on fine and works properly. I'll install a firmware update on it and place it back but don't have a lot of trust that that will change anything.

anyone got tips / an idea i could try next? don't feel like switching the t-con board since i dont want to risk to much on the working display.

[platinum95]

Try capturing the UART output from the mainboard and TCON, it's pretty informative and should help you narrow the fault down.

The Mainboard UART breakout is on the back of the board, on connector CN805_DB at the edge. Tx is pin 2.

TCON has 2 UART breakouts, one for each SoC. They're part of the debug pads next to the SoCs, and are labelled. Tx is "MDBG_TX" and "SDBG_TX" for the Master and Slave SoCs.
Images attached for both boards.

They're 3.3v lines, so most UART-capable things should be able to read them.

[Newb2000]

Thanks, very helpful. I'm waiting on a new soldering pin after it arrives i'll test it. one more question:

Do you also know which pin on CN805_DB is RX? I found the hidden serial shell in firmware and would like to try interacting with it after I capture the boot log.

[platinum95]

Not sure which is Rx, unfortunately the mainboard's silkscreen labels are a bit more sparse. I found Tx by just probing around.

That's interesting about the serial commands though, if you have a chance could you share more info? I hadn't been able to find a firmware for the mainboard to inspect. I'm curious if there's anything in there for syncing the display calibration data which would be useful for this display I have.

[Newb2000]

Quick update: I actually got UART working in the meantime.

The mainboard log is constantly spamming:

SecDrvTcon_ReadPowerOnStatus: 00 00 00 00

over and over, exactly like in your case.

So between that and the motherboard swap test I did earlier, it’s looking more and more like the same T-CON-side failure.

I also managed to get hold of the official Samsung firmware packages and did some AI-assisted analysis on them.

The current public mainboard firmware (M-C9349GGAA-1011.0) contains a hidden UART debug console with a T-CON menu, including things like:

• T-Con Flash Dump
• T-Con FW Update
• T-Con Data Update
• Tcon version
• T-Con Read/Write Control Register
• T-Con Print status values
• T-Con Reset(PWR Off/On)

There’s also a general shell mode with help.

I also found an older official G93SC 1005.2 package containing separate T-CON firmware files:

49A2ODYOC.bin
49A2ODYOCSUB.bin

Those are definitely the main/sub T-CON application firmware. The analysis found the exact same Boot GPIO CNT Over / system reset! path you saw. It polls GPIO5 during boot, times out, and resets.

The interesting bit is that the scaler firmware seems to have built-in tools for dumping/updating the T-CON, although I haven’t confirmed yet what exactly T-Con Flash Dump covers or whether T-Con Data Update has anything to do with panel calibration.

I haven’t managed to identify the mainboard RX pin yet, so for now I can only listen to UART. If you happen to know which CN805_DB pin is RX that would be extremely useful.

Also, soldering that tiny UART wire after not touching a soldering iron for years was honestly way more painful than expected 😅, but at least TX is working now.

Next I want to capture the two T-CON UARTs at MDBG_TX and SDBG_TX and see if mine is also doing the same magickey error -> FW2 -> Boot GPIO CNT Over -> system reset! loop.

[Newb2000]

I’ve now confirmed both MDBG_TX and SDBG_TX show the exact same FW1 magickey → FW2 → Boot GPIO CNT Over → reset loop as yours. Do you still have a photo/pinout of the SWD pads you used for the Master/Slave SoCs, and which Pico Debug Probe pins you connected to SWDIO/SWCLK/VTref/GND?

[platinum95]

That's great info, thanks. I'm away at the moment but when I'm home I'll see if I can find Rx and drop into the shell. If the mainboard happens to store a copy of the calibration data this would simplify things a lot, probably wishful thinking though.

For TCON debugging, I attached to S_SW_DIO1 and S_SW_CLK for the slave, and equivalent M-prefixed pads for the master SoC. These connect to SWDIO, and SWCLK on the debug probe. I didn't connect VTref since the probe operates at 3.3v anyway. I connected ground via an alligator clip to one of the metal tabs/clips that secure the PCB, to avoid soldering another fragile lead. On that note, I'd suggest taping up your soldered cables well, and keep them insulated. Don't make the same mistake I did by frying the board with a loose wire, it's a bad time. For my second attempt I've been using "logic analyser hook leads", they're spring loaded and "suck" the wire into an insulated jacket which has been working a lot better.

I can send over my patch scripts etc. when I'm home, they might be useful since it seems your board has the same fault as mine.

[Newb2000]

That’s perfect, thank! Really useful to know the exact SWD pads and that you didn’t need VTref.

I’ve got a Raspberry Pi Debug Probe on order now, so I’m basically waiting for that to arrive before I can continue on the SWD side. I’ve already got the soldering gear and thin wire sorted, and I’ll definitely take your advice on securing/insulating the leads properly after seeing what happened to your first board.

I’m also interested to see whether you manage to get into the mainboard shell and whether any of those T-CON dump/data commands expose calibration-related stuff. That could make the replacement-board route a lot less painful if the calibration can be backed up or restored somehow.

[platinum95]

Quick copy-paste of my limited look at those edge connectors.

CN80X_DB - 5 connectors on edge of mainboard.
Pin 4 is GND, all connected together.
Pin 1 all have a missing component, BD80X_DB, that would connect them to a common bus. That bus is held high at 3.3v, with some transients on it. Likely interference.
Pin 2 on CN804_DB is Tx for main processor, and is active with log messages. Pin 2 on other Connectors is held high but with no activity. Possibly Tx for other components?
Pin 3 is low with some transients. Best contender for Rx.

Pin 2/3 on each connector all have traces that go to the same area on the other edge of the board, at which point they all enter a via that connects to some intermediate layer in the PCB since there are no traces coming out on either side of the board.

I connected my UART probe up to Pin 3 and ran my patch to get the monitor to boot up fully, but couldn't get the Mainboard to respond to any queries over the suspected Rx. It's possible that I'm missing some special sequence to get into the debug commands, or possibly some other pin has to be pulled low (maybe pin 1?).

[platinum95]

Here are some of the configs/scripts that might be useful: https://github.com/platinum95/SamREpair. Forum wouldn't let me upload them directly.

tcon_m.cfg and tcon_s.cfg are the configs for openocd for the master and slave SoCs. You'll have to update the serial IDs in each for your own debug probes. Use them as `openocd -f tcon_s.cfg`. Start a separate session for both Master and Slave. They'll listen for telnet connections on port 4444 and 4445, and tcl connections on 6666 and 6667. These ports can be changed to whatever.

tconutils.tcl and tcondump.tcl are utility/helper scripts for within openocd. When connected via telnet, you can import them via `source <path to file>.tcl`. There are some useful commands within them, `tcon_halt_at_scan` is probably the most useful, it'll halt the process at a semi-stable point during the boot loop for memory inspection etc.. tcondump.tcl builds off those utils to dump larger/known sections of the eMMC.

patch2.py runs the transient patch against the running openocd sessions. Once you're all connected up, running this patch should allow the screen to boot up properly. This patch doesn't persist across boots, it just bypasses the GPIO handshake once.

I have some steps as well for restoring the magic-key sections of FW1 in the eMMC, which is a more permanent fix (though may fail again due to the original fault). I can post those if they're useful.

Note that all these steps are not 100% reliable, there are some timing issues around the SoCs boot loop, i.e. running the patch script too early/late in the boot cycle may not allow it to take hold. It usually succeeds on subsequent attempts.
Note also that everything here is strongly tied to the firmware I pulled off my own board, so if another board has a different build it likely won't work. Check the build timestamp from the UART output and compare against my own (Keil 5060183, Build(Apr 23 2023 14:06:03)).

[Newb2000]

That’s massively helpful, thanks. I’ve now got one Raspberry Pi Debug Probe in hand and I’ve already confirmed its UART side works with the T-CON logs, so I’m moving onto SWD next.

I’ve also ordered a second Debug Probe now after looking at your patch2.py and seeing that it expects two OpenOCD instances at the same time for Master and Slave. Bit annoying to need another one, but at least the setup is very clear now.

My UART output matches your board exactly on both SoCs, including:

FW#1_CORE0 magickey error(0x0)
BL1 EMMC FW#2 core0,1
Boot GPIO CNT Over
system reset!

and the same Keil 5060183, Build(Apr 23 2023 14:06:03) timestamp, so it looks like your patch should be a very good fit for mine.

I’ll first try getting read-only SWD access working on the slave with S_SW_DIO1 / S_SW_CLK, then once the second probe arrives I’ll bring up both OpenOCD sessions and run the dry-run before touching anything.

Also thanks for posting the scripts — that saves me a ridiculous amount of reverse engineering. The resume ordering in patch2.py makes a lot more sense now too.

If you still have the steps for restoring the FW1 magic-key section later, i would definitely appreciate those as well.

I'm at work right now, i'll have an ai agent look into getting in the debug shell once i get home.

[Newb2000]

Quick follow up. I've downloaded the firmware again and let claude and fable run it. The debug shell is protected by a password.

How you get in

The menu is a UART console on the main board, not a key combo on the OSD joystick. The entry sequence is:

1. Wire up the scaler UART. Find the debug TX/RX/GND pads on the main board and attach a 3.3V USB-to-serial adapter. We never recovered the baud rate from static analysis (the UART base is set up at runtime, not a literal), so try the Samsung-typical rates in order: 115200, then 9600, 921600, 57600. You'll know the rate is right when boot text is readable.
2. Type the magic key to unlock input. The console ignores keystrokes until you type a specific character sequence. As you type, it echoes %d th key is %c for each correct character, and prints BINGO!!! MAGICKEY!!!! unlock serial input. when the full sequence matches. That per-character echo is a progress oracle.
3. Open the menu. Once unlocked, you get [Monitor debug Menu]. Navigate to SecLib, then the T-Con submenu, or use 98. Shell mode for the full command shell.

The thing is claude is claiming that it's very easy to brute force this key since the board has a count of the correct characters typed in. so basically i let it write a script that just does this one by one ill test it out tonight and if it works send you the key or the script in case keys are not the same per monitor

[Newb2000]

Quick update from today, made quite a bit of progress.

I first tried the suspected mainboard RX path on CN804_DB pin 3 while keeping the known-good TX connected. I can still read the normal mainboard UART spam, but I couldn’t get any response from the hidden debug shell. So either pin 3 isn’t RX, the console needs some extra enable condition, or the magic-key input is gated somehow. I’ve parked that for now before I turn this into another rabbit hole 😅

The more useful part is that I got SWD working on the slave T-CON SoC with a Raspberry Pi Debug Probe.

OpenOCD sees:

SWD DPIDR 0x0bd11477
Cortex-M7 r1p2 processor detected

and manual halt works.

I checked all 7 patch locations from your patch2.py directly on the hardware and they all match:

0x277E = 0xB918
0x29E6 = 0xB97C
0x29E8 = 0xB975
0x29FE = 0xF003
0x2A00 = 0xFD05
0x2A02 = 0xF000
0x2A04 = 0xF80D

I also dumped the running slave FW2 from RAM and did some AI-assisted Ghidra analysis on the actual dump. It confirms the patch logic exactly. FW2 gets stuck on the GPIO5 handshake path, and the failure branch calls the eMMC blanking routine and then system_reset().

The biggest finding is that 0x640C really does zero the first 512 bytes of eMMC sector 0. So the FW#1_CORE0 magickey error(0x0) isn’t random corruption, the firmware deliberately nukes the FW1 header after a failed boot. Bit of a questionable recovery strategy from Samsung there 😅

I then used the existing eMMC read helper over SWD and confirmed:

• sector 0 is 512 bytes of zeros
• FW1 body is intact
• FW2 body is intact
• FW1 and FW2 bodies are byte-identical on this unit
• config blobs all validate
• nothing else obvious looks damaged

Also, on this unit FW2 is actually at eMMC 0x500000, not 0x478000. That 0x478000 value was just the offset inside the package file.

So right now it really looks like the only persistent damage is the missing FW1 header sector.

The only thing stopping me from doing a clean permanent restore is that two header fields still aren’t understood well enough to guess safely, +0x1FB and the 4-byte word at +0x1FC.

Would you happen to still have a dump of sector 0, or just the 512-byte FW1 header, from one of your working T-CONs with the same April 23 2023 build?

Even just that tiny sector would be massively useful. If the build matches mine, I should be able to compare it against my FW2 header and reconstruct the missing FW1 header without touching any calibration data.

I’ve also got a second Debug Probe on the way, so next I’m planning to try your transient two-SoC RAM patch before I write anything persistent.

[platinum95]

The "permanent" patch I have is to just copy FW2's header (first 512 bytes) into the missing spot of FW1's header, under the assumption that the builds are similar enough for it to work. if you look at FW2's header it's mostly empty, mainly has build info and the magic key so it's relatively low risk.
It worked for me and persisted across reboots, but the error handler that zeroes out the header still exists and is pretty easy to trigger while debugging, e.g. if the SoCs go out of sync because one is halted and the other isn't.

Patch content is below. It basically just copies FW2 header into working memory, then writes it out to FW1's header location on eMMC, along with some validation steps.
I had tried getting it into a similar python script like the transient patch but got impatient so just ran the commands one by one in telnet. You'll have to run these steps on both the Master and Slave SoCs, while they're both halted. Make sure you keep them both halted until they're both done, since resuming one post-patch without the other running will cause them to go out of sync and the firmware will zero out the header again. When both are patched and in the halted state, cut the power, wait a few seconds, then plug back in the power. This just makes sure they stay synced.

source /path/to/tconutils.tcl
tcon_halt_at_scan
                                                    ; expect: stopped at 0x000029c2

tcon_call 0x00006A98 0 0x2021C200 0 0x200 0         ; expect 0
read_memory 0x2021C200 32 4                         ; expect 0x0 0x0 0x0 0x0  (blank)

tcon_call 0x00006A98 0 0x2021C000 0x500000 0x200 0  ; expect 0
read_memory 0x2021C000 32 4                         ; expect 0xa5a55a5a 0x0 0x0 0x0
read_memory 0x2021C1F8 32 2                         ; expect 0xf1000042 0x2cd4c603

                                                    ; STOP unless the above match

tcon_call 0x00006DD4 0 0x2021C000 0 0x200 0         ; expect 0  (the write)

tcon_call 0x00006A98 0 0x2021C000 0 0x200 0         ; expect 0
read_memory 0x2021C000 32 4                         ; expect 0xa5a55a5a 0x0 0x0 0x0
read_memory 0x2021C1F8 32 2                         ; expect 0xf1000042 0x2cd4c603

[platinum95]

The only thing stopping me from doing a clean permanent restore is that two header fields still aren’t understood well enough to guess safely, +0x1FB and the 4-byte word at +0x1FC.

Would you happen to still have a dump of sector 0, or just the 512-byte FW1 header, from one of your working T-CONs with the same April 23 2023 build?

Unfortunately both TCONs I have started off with a blanked header for FW1.

Here's some copy-paste from when I was looking at the header structure. It's from an AI so take it with a grain of salt, it seems to like to assert things confidently that haven't been confirmed:

---------
FW#2 header contents (the bytes written)

0x000 5A 5A A5 A5 magic
0x040 "230423A" version code
0x060 "SDCAD\dongki.eun" builder
0x080 "04-23-2023 14:06:48" build timestamp
0x0A0 "MODEL_DQHD_MNT"
0x0C0 "ARMCC_5.06.0.45"
0x0E0 "aca8057 2023-04-22" git hash
0x100 "QD_SW_AP_Q250A.git (fetch)"
0x120 "Commit is needed"
0x1F8 42 00 00 F1 "type" field BL1 validates
0x1FC 03 C6 D4 2C body checksum

The Apr-2025 update file's header differs at 0x1F8 (42 00 00 89) and
0x1FC (03 D6 78 B7) — pairing it with a 2023 body would fail. Writing
only the magic gives type error(0x0), confirming 0x1F8 is checked.
--------

[Newb2000]

NOTE: Fully ai generated response:

We actually pulled BL1 off the running SoC over SWD and disassembled its header check, so those two fields aren't guesses any more. The important part first: you don't need a donor sector 0. A byte-for-byte copy of your own FW2 header (eMMC 0x500000) written to LBA 0 is a valid FW1 header, because BL1 checks nothing slot-specific.

Your AI's parse of the trailer is off. The 8 bytes at 0x1F8 are four separate fields, not a type dword + a checksum dword:

+0x1F8 0x42 type byte BL1 checks == 0x42
+0x1F9 0x00 0x00 padding not checked
+0x1FB 0xF1 CRC-8 of body BL1 checks == crc8(body[0 : size])
+0x1FC 03 C6 D4 image size big-endian 24-bit = 0x3C6D4 (247508), BL1 checks 0 < size <= 0x3FE00
+0x1FF 0x2C not read by BL1 at all

So the two fields you're missing:

- +0x1FB is not a mystery, it's a CRC-8 of the body. Table-driven, init 0, no final XOR, over exactly size bytes of the body. Because your FW1 body is byte-identical to your FW2 body (ours were: 0 differing bytes across the whole slot), the CRC is identical too, so the value you already have in your FW2 header is correct. You can also just compute it.
- +0x1FC is not a 4-byte word. It's the 24-bit big-endian image size (bytes 0x1FC..0x1FE) plus one trailing byte at +0x1FF that BL1 never reads. Both come straight from your FW2 header.

The exact BL1 logic (routine at RAM 0x202004E0 on the running SoC), in order: magic == 0x5A5AA5A5, then byte +0x1F8 == 0x42, then 24-bit BE size in range, then +0x1FB == CRC-8 of the body. That's the whole check. No signature, no monotonic counter, no slot id, and +0x1FF is ignored. That also explains your own observation: writing just the magic gives type error(0x0) because the next check, +0x1F8, is then zero.

CRC-8 table (256 bytes, lifted from BL1 at 0x20202B71), if you want to verify a candidate header against a body yourself:

00d57faafe2b815429fc5683d702a87d52872df8ac79d3067bae04d18550fa2f
a471db0e5a8f25f08d58f22773a60cd9f623895c08dd77a2df0aa07521f45e8b
9d48e23763b61cc9b461cb1e4a9f35e0cf1ab06531e44e9be633994c18cd67b2
39ec4693c712b86d10c56fbaee3b91446bbe14c19540ea3f42973de8bc69c316
ef3a904511c46ebbc613b96c38ed4792bd68c21743963ce99441eb3e6abf15c0
4b9e34e1b560ca1f62b71dc89c49e33619cc66b3e732984d30e54f9ace1bb164
72a70dd88c59f3265b8e24f1a570da0f20f55f8ade0ba17409dc76a3f722885d
d603a97c28fd5782ff2a805501d47eab8451fb2e7aaf05d0ad78d20753862cf9
c = 0; for b in body[:size]: c = table[c ^ b] — that's the value that must land at +0x1FB.

Your Apr-2025 file data actually fits this perfectly: 0x1F8 42 00 00 89 means CRC-8 0x89 (the 2025 body has a different CRC), and 0x1FC 03 D6 78 B7 means size 0x3D678 with 0xB7 as the ignored trailing byte. Pairing it with a 2023 body fails on both the CRC and the size, exactly as you saw, no signature involved.

One caveat we hit that's worth flagging before you write: restoring only one SoC's LBA 0 self-destructs. A lone FW1 chip runs the boot handshake, waits for its partner's GPIO20, times out against the still-FW2 partner, and the firmware re-zeros its own LBA 0 (that's what blanked it originally, a function that memsets 512 bytes and writes them to LBA 0 after a failed handshake). So both SoCs need their header restored in the same power cycle, held halted until both writes verify.

Happy to share the full BL1 disassembly and a small verify script if useful.