Why This ASUS B650E-F + RTX 5090 + High-Refresh Display Failure Is Almost Impossible to Diagnose Without Synthesis
Literally, without AI I could not have solved this problem. Too unique / hard to google, etc. It’s absolutely wild the information it synthesized about likely hardware failure paths unique to my exact symptoms (i.e what does it mean when HDMI cable on Motherboard works, but not DP, but orange light, 1 ram stick in/out, one RGB on etc.
Keywords for those with the same problem:
ASUS B650E-F BIOS flashback, AM5 orange DRAM light, LED firmware update loop, RTX 5090 no DisplayPort signal, GPU not detected after BIOS update, DisplayPort only works with HDMI, Aura firmware crash, AI training hard shutdown PC
Most of this is AI generated but here we go:
TL;DR (for people in crisis)
If your AM5 system appears bricked after a hard shutdown during AI training and shows some combination of:
- Endless “BIOS is updating LED firmware” loops
- Orange DRAM Q-LED that never clears
- No video output from GPU
- DisplayPort working only if HDMI is also plugged in
Your hardware is probably not dead.
What you’re dealing with is partial firmware corruption + display initialization order failure, triggered by a very specific hardware/software combination.
The fix required:
- USB BIOS Flashback (oldest stable BIOS)
- Aura / RGB firmware isolation
- AM5 memory retraining patience
- iGPU → dGPU handoff reset
- HDMI as a temporary EDID bootstrap
- Forcing DisplayPort to become the primary display
- Clean NVIDIA driver re-enumeration
This cannot be solved by a single forum post or vendor doc. It requires cross-layer synthesis.
The Trigger: Hard Shutdown During AI Training
The system didn’t crash while browsing or gaming.
It hard-powered off during AI model training — sustained, atypical load.
The Perfect Storm: Why This Hardware Combination Is Fragile
This issue is far more likely with this exact stack:
1. AM5 Platform (Ryzen 7000 / 7800X3D)
- Extremely aggressive memory training
- Multiple firmware reinitialization passes
- Sensitive to BIOS downgrades and CMOS clears
2. ASUS ROG Boards with Aura / RGB
- Separate LED MCU firmware
- Can enter recovery loops if interrupted mid-write
- Not isolated from power events the way main UEFI is
3. RTX 5090 (Next-Gen NVIDIA GPUs)
- Complex PCIe enumeration
- More aggressive power state transitions
- Heavier reliance on driver-managed display init
4. High-Refresh DisplayPort Monitor (240 Hz / 4K / VRR)
- Stateful DisplayPort link training
- EDID negotiation happens later than HDMI
- Much easier to fail silently after firmware resets
5. AI Training Workloads
- Sustained GPU power draw
- No “natural breaks” for clean state sync
- Hard shutdown hits at the worst possible moment
Individually, none of these are a problem.
Together, they create a non-linear failure mode.
What Actually Broke (and What Didn’t)
Not broken:
- CPU
- RAM
- GPU
- Motherboard traces
- Power supply
Broken / confused:
- LED / Aura firmware state
- BIOS assumptions about primary display
- GPU display initialization order
- NVIDIA driver display cache
- DisplayPort EDID handshake timing
This is why the system looked dead while being electrically fine.
Why USB BIOS Flashback Was Critical (and EZ Flash Wasn’t)
USB BIOS Flashback:
- Runs on a dedicated microcontroller
- Ignores CPU, RAM, GPU, OS
- Bypasses the LED / Aura firmware path entirely
This is not just “another way to update BIOS.”
It is firmware isolation, and it’s the only reason recovery was possible.
Key details that mattered (rarely documented clearly):
- Using the oldest stable BIOS, not the newest
- FAT32 + MBR formatting (macOS-safe)
- Correct manual BIOS filename
- Unplugging RAM and RGB during Flashback
The Orange DRAM Light: Why Waiting Was the Right Move
After Flashback:
- System rebooted
- Orange DRAM Q-LED stayed on
- No video
On AM5, this often means:
- Full memory retraining
- Multiple internal reboots
- Training restarting after any BIOS change
Interrupting this is how people brick boards.
Minimal config + patience was the fix:
- One RAM stick
- Slot A2
- No GPU
- No RGB
The Most Confusing Symptom (and the Key Insight)
DisplayPort only worked if HDMI was also plugged in.
This sounds like black magic. It isn’t.
What was happening:
- HDMI provided an early, guaranteed EDID handshake
- NVIDIA successfully initialized the display engine
- DisplayPort trained after that
- Without HDMI, DP never initialized
HDMI wasn’t the solution — it was the bootstrap device.
This is a known (but undocumented) NVIDIA + DP + high-refresh edge case after firmware resets.
The Fix That Made It Stick
- Boot with HDMI + DisplayPort
- Enter Windows
- NVIDIA Control Panel:
- Set DisplayPort as primary
- Full shutdown
- Remove HDMI
- Cold boot on DP only
That forced NVIDIA to rewrite its display initialization path.
After that: DisplayPort worked independently forever.
Why This Couldn’t Be Solved by Google
No single source explains:
- LED MCU firmware loops
- AM5 memory training behavior
- iGPU ↔ dGPU boot path caching
- NVIDIA EDID initialization order
- DP vs HDMI protocol differences
- AI-training-specific shutdown risk
Each exists in isolation across:
- Vendor docs
- Scattered forum anecdotes
- RMA support scripts
- Driver changelogs
What solved this wasn’t information — it was synthesis:
- Maintaining a causal model across firmware, hardware, drivers, and protocols
- Reducing state space step by step
- Applying changes in the only order that works
That’s why this felt “impossible” — because lookup alone was insufficient.
Final Advice (If You Ever See This Again)
- Avoid Aura / Armoury Crate on AM5 if you value stability
- Don’t BIOS-update unless you need a fix
- If you see LED firmware update loops, stop immediately
- Unplug all RGB (better-yet unplug GPU, RAM) — Flashback to older BIOS for your Motherboard w/o RGB controllers
- Use Flashback, not EZ Flash
- Use HDMI to rule out DP handshake issues
- If DP disappears after recovery, use HDMI once — intentionally
- DP may only work w/ HDMI at same time (not DP alone) – Set DP to primary with dual connected, then restart w/ HDMI cable removed.
This wasn’t a broken PC.
It was a distributed system stuck in an invalid state.
And those are only fixable if you understand the whole system.
Yuji Tomita 