NUCLEO-N657 schematic discrepancy vs AN5967 regarding VDDA18PMU / VDDSMPS

[Vinayak_MK]

Discrepancy between AN5967 and MB1940 schematic regarding VDDA18PMU / VDDSMPS connections in external SMPS mode

Hello ST Team,

We have a custom board based on the STM32N657X0H3Q, designed using the MB1940 (Nucleo-N657X0Q) schematic as reference. The board has been fabricated and assembled, and we are currently in the bring-up phase.

During bring-up we encountered a failure on the external SMPS path (TPS62088YFP) used for VDDCORE generation. The external buck failed with a shorted high-side FET, driving 5V directly onto the VDDCORE rail. After investigation, we recovered the board by removing the failed external buck and switching to the on-chip internal SMPS, which is currently working correctly and supplying VDDCORE at 0.810 V.

While reviewing the power supply architecture during this debug, we noticed a discrepancy between AN5967 (Getting started with hardware development for STM32N6 MCUs) and the MB1940 reference design that we would like clarification on.

---

Discrepancy

AN5967, Section 3.1, states explicitly:

"VDDSMPS: external power supply for the SMPS step-down converter." Note: This power supply must be tied to VSS when the SMPS is not used.

"VDDA18PMU: external analog power supply for the SMPS step-down converter — 1.8 V typical." Note: This power supply must be tied to VSS when the SMPS is not used.

AN5967, Figure 4 (System supply configurations) also clearly shows that in the bypass mode (external SMPS / SMPS off), all SMPS pins (VDDSMPS, VDDA18PMU, VLXSMPS, VFBSMPS, VSSSMPS) should be tied to VSS.

However, in the MB1940 schematic (page 9):

When the board is configured to use the external TPS62088YFP buck (U17) for VDDCORE generation:

• VDDA18PMU is connected to the 1.8V rail (not VSS)
• VDDSMPS is connected to the 1.8V rail (not VSS)
• The full internal SMPS network (inductor on VLXSMPS, caps on VFBSMPS) remains populated

The internal SMPS appears to be disabled only via firmware (clearing SDEN in PWR_CR1), not by hardware.

---

Questions for ST Technical Team

1. Which guidance is correct for production designs using an external SMPS for VDDCORE?
   • Should VDDA18PMU and VDDSMPS be hardware-tied to VSS as AN5967 states?
   • Or is it acceptable to leave them connected to 1.8V as MB1940 implements?
2. If MB1940's approach is acceptable, what is the role of the AN5967 note? Is it a worst-case safety statement, or is there a real failure mode if VDDA18PMU/VDDSMPS are left at 1.8V?
3. Boot ROM behavior: Since SDEN defaults to '1' (internal SMPS enabled) at reset, there is a window between POR release and firmware execution where the internal SMPS is active. If an external buck is also driving VDDCORE during this window, are there any concerns about contention, current spikes, or stress on either regulator? Could this contribute to the kind of external buck failure we observed?
4. For a custom board not requiring power measurement (i.e., not needing the I_SENS lines that MB1940 exposes via CN12), what does ST recommend?
   • Use internal SMPS only (Option 1 in AN5967 Figure 4) and not populate the external buck circuitry?
   • Keep the MB1940 architecture as-is?
   • Any guidance on when external SMPS provides a real benefit over internal SMPS?
5. External buck reliability: Has ST observed any specific failure modes with the TPS62088YFP in the MB1940 external SMPS path? The DSBGA package is sensitive to handling and reflow conditions, and a hard failure of the high-side FET drives VIN (5V) directly onto the VDDCORE rail — which is what we observed on our board. Are there any recommended protection measures (TVS clamp, fuse, etc.) that ST suggests for the external SMPS path?

---

Why This Matters

For engineers using MB1940 as a reference for custom production boards, this discrepancy creates uncertainty about which guidance to follow. A clear answer from ST will help avoid:

• Incorrect hardware implementation that violates AN5967 requirements
• Unnecessary complexity if MB1940's approach is acceptable
• Potential reliability issues if the external SMPS path is used incorrectly — as we experienced

A clarifying note in a future revision of AN5967 — explicitly addressing how MB1940 implements the external SMPS option and what production designs should follow — would be very helpful for the community.

Thanks in advance for the clarification.

Regards,

Vinayak

[FBL]

Hello @Vinayak_MK 

Thank you for highlighting the issue.

An internal ticket is submitted to dedicated team to clarify the correct implementation. For internal reference : CDM0062264