I'm trying to debug/flash a FRDM-MCXE31B board and consistently hit a RAM initialization failure during the connect sequence, before any application code loads. I've ruled out wiring, cables, USB ports, jumpers, and probe firmware — details below.
Setup:
- Board: FRDM-MCXE31B
- M C U: MCXE31B
- Tested with: M C U X Presso IDE v25.6 (Windows) and standalone Link-server v26.6.137 (Ubuntu Linux) — same failure on both
- MCU-Link onboard probe firmware: updated to v3.172 (confirmed matching, no version mismatch reported)
- Connect script: MCXE31x_connect.scp
What works:
- SWD physical connection succeeds
- Debug authentication/unlock succeeds ("application debug already enabled")
- Chip identification succeeds — reads back correct part number:
SIUL2:MIDR1 @ 0x40290004 = 0x6BA02477
MCU Part Number is 0x000003A0
Where it fails — every attempt, both OSes:
... RAM init via eDMA: address=0x20400000 size=0x00028000
Error: Wire Ack Fault - target connected? [repeats ~46 times]
Error: RAM initialization failed (timeout)!
This leads to: Failed on connect: Ep(01). Target marked as not debuggable.
Context I found that may be relevant: I understand from the S32K3 reference manual (same architecture family) that ECC-protected RAM on these parts must be initialized via a 64-bit master write before any 32-bit access is valid after power-on-reset — so I assume this eDMA step in the connect script is performing that mandatory initialization automatically. It appears to be this automated step itself that's timing out, not a wiring/connection issue, since chip identification (steps before this) succeeds cleanly every time.
Question: Has anyone else hit this specific failure on FRDM-MCXE31B? Is there a known workaround, updated connect script, or a way to skip/adjust the automatic RAM-init step? Happy to provide full verbose logs (Link-server -l 5) if useful.