STM32MP257F-EV1 (MB1936D) not booting after PA6/PA7 rework for MDF1 — no console output, no USB DFU enumeration
Subject: STM32MP257F-EV1 (MB1936D) not booting after PA6/PA7 MDF1 rework + SAI2 speaker addition — no console output, no USB DFU enumeration
Board: STM32MP257F-EV1, board reference MB1936D
Background — MDF1 microphone rework:
We were bringing up PDM microphone capture on MDF1 (channel 6, PA6=SDI6, PA7=CCK0). On this board revision, PA6/PA7 are hardwired only to the onboard RTL8211F Ethernet PHY (ETH3.TXD0/TXD1 via series resistors R169/R175) with no external header access. To route these pins to MDF1 instead, we physically soldered a wire tap onto R169 and R175, and disabled Ethernet in our device tree so MDF1 could claim PA6/PA7 without a pinmux conflict.
Background — speaker interface addition (same device tree, added afterward):
Separately, we added a playback path using a MAX98357A I2S digital audio amplifier driving a 4Ω/5W speaker, over SAI2A:
- CN5 pin 12 (PJ11, SAI2_SCKA) -> MAX98357A BCLK
- CN5 pin 35 (PJ3, SAI2_FSA) -> MAX98357A LRCLK
- CN5 pin 38 (PJ12, SAI2_SDA) -> MAX98357A DIN
- CN5 pin 39 -> GND, CN5 pin 2/4 (5V) -> VIN
- MAX98357A OUT+/OUT- -> speaker
Device-tree additions: an audio-graph-card playback node, a max98357a amplifier node, SAI2/SAI2A enabled with pinctrl for PJ11/PJ3/PJ12 at AF4 (pinctrl placed on the parent &sai2 node, not &sai2a, per the STM32MP257 pinctrl driver). The existing MDF1 microphone configuration was preserved unchanged alongside this. CONFIG_SND_SOC_STM32_SAI, CONFIG_SND_SOC_MAX98357A, and CONFIG_SND_AUDIO_GRAPH_CARD were already enabled as kernel modules — no new driver needed. The updated device tree compiled successfully via bitbake (linux-stm32mp -c compile -f), producing a new stm32mp257f-ev1.dtb.
After deploying this combined DTB (MDF1 mic + SAI2/MAX98357A speaker), the board booted normally and we successfully validated both: MDF1 PDM microphone capture, and initial speaker interface bring-up — over what we estimate was a full working session.
Current issue:
Some time after that working session, the board stopped booting. Current symptoms:
- Main power LED and ST-Link LEDs (LD5/LD6/LD11) light normally.
- ST-Link enumerates correctly on the host PC (lsusb shows ID 0483:3753, STMicroelectronics STLINK-V3) and exposes /dev/ttyACM0 and /dev/ttyACM1 normally.
- No boot log/console output appears on either ttyACM port at 115200 8N1 (flow control disabled, confirmed via minicom) even after multiple full power cycles and reset-button presses.
- RJ45 link/activity LEDs (LD3/LD4) are dark, which we believe is expected since Ethernet is disabled and PA6/PA7 are now redirected — not something we're currently chasing.
- Boot switches (SW1) were confirmed via close-up photo to be correctly set for eMMC boot (BOOT.0=OPEN, BOOT.1=OPEN, BOOT.2=CLOSE, BOOT.3=OPEN) per the documented table.
- We then set all 4 switches to OPEN (USB Serial Downloader / System Bootloader mode) and did a full power cycle with a USB cable connected to the USB DRD (OTG) port. No device of any kind enumerates on the host (lsusb shows nothing new), and dmesg shows zero USB attach-event kernel messages for that port — not even a failed/partial enumeration attempt.
What we've ruled out so far:
- ST-Link itself is healthy and enumerates in normal mode (not stuck in loader/DFU mode, ID 0483:374d).
- Verified continuity/short check on the PA6/PA7 tap wires and solder joints — no short to GND or 3.3V found at the tap points themselves.
- Confirmed boot switch positions physically via photograph against ST's documented eMMC/USB boot tables.
- Tried both ttyACM0 and ttyACM1 for console output.
Questions for the community/ST:
1. Is there a known dependency between the ETH3.TXD0/TXD1 (PA6/PA7) signal path and the boot ROM or USB OTG/DRD initialization sequence on STM32MP257 that could cause the SoC to hang before ever reaching USB enumeration, even with boot switches correctly set to USB Serial Downloader mode?
2. Could enabling SAI2/SAI2A alongside the MDF1 pinctrl change introduce any clock-tree (RCC) contention that might affect boot-time peripheral init, given both share nearby GPIO ports?
3. Beyond the SW1 boot switch positions, are there any other preconditions (e.g., specific reset sequencing, RCC/clock strap requirements, or OTP-related boot config) needed for the STM32MP257 boot ROM to present itself over USB DRD for recovery flashing?
4. Given zero console output and zero USB enumeration (not even a failed attempt), what's the recommended diagnostic path to determine whether this is an eMMC/bootloader corruption issue versus a SoC-level hang, without assuming board damage?
We're planning to attempt an SD-card boot as a parallel recovery path to isolate whether this is eMMC-specific, but wanted to raise this here in case either the PA6/PA7 rework or the SAI2/MAX98357A addition has a known interaction with boot behavior on this board that we're not aware of.
Happy to share oscilloscope captures, dmesg logs, device-tree snippets, or photos of the rework on request.
Thanks,
Radha
