NUCLEO-H5E5ZJ — Redrawing the Schematics as a GPIO View

[rich.g.williams]

 

I have redrawn the NUCLEO-H5E5ZJ schematic as a personal exercise in understanding the architecture of the board and the STM32H5E5. I have consolidated the original multi-sheet design into a main STM32H5E5 schematic and a separate STLINK schematic, using port objects to make the principal interconnections explicit. During the redraw, I cross-checked the connectivity against ST's original Altium design files and the more recent PDF schematics.

My aim was to show the MCU GPIO ports rather than their alternate functions, as I found this gave me a different picture of how the MCU is connected to the board. The exercise also revealed just how much functionality is exposed by the NUCLEO-H5E5ZJ PCB: the usefulness of the M.2 Key A socket, the extensive possibilities offered by the other headers, and, in particular, the surprisingly large number of MCU GPIOs that are brought out to them and are available.

I have a great deal of respect for the NUCLEO-H5E5ZJ PCB and for the STM32H5E5. The capabilities and functionality provided by this device are considerably beyond anything I have previously encountered in a microcontroller.

I am posting the two PDF schematics here in the hope that other engineers may find them useful. They are the most recent versions as of 4 September 2026.

Richard Williams
 

[rich.g.williams]

updated drawing 

[rich.g.williams]

Here is another example of how I have used 5e5_main_v2.pdf to help select pins.

By using 5e5_main_v2.pdf I can quickly search through a port to see where it is on NUCLEO PCB connectors and see if it is committed, here is an example showing highlighted ports I chose for FDCAN1 Tx and Rx:-

I selected these alternates using ST Core MX on the pinout view:-

Also using the official NUCLEO-H5E5ZJ PCB schematic I found SPI4 already labelled and brought out to CN5 and CN10 as is already on the PCB and the official NUCLEO-H5E5ZJ PCB schematic. 

Then I found pins for SPI1 using MX and 5e5_main_v2.pdf again checking they were free. I found that PA5 for SPI1_SCK was not free on the PCB, (its used for Ethernet PHY) so selected an alternate PG11 as SPI1_SCK.

And the great thing is that ST Core MX writes the configuration code automatically! Very impressive, well done ST!

Any comments (good or bad) much appreciated.

Thank you, 

Richard

 

[db16122]

Thanks for your request.The system seems to be designed as EVK function including Deduging，USB power supply and Ethrnet connection etc. Do you plan to design on-board debuging as well or STlink only？

[rich.g.williams]

Thanks for looking at the schematics!

To clarify, I’m not designing a new custom PCB here. These schematics are a complete, redrawn reference map of the official ST Nucleo-144 (MB2129) baseline, specifically covering the STM32H5E5ZJT6 processor populated on my NUCLEO-H5E5ZJ boards.

My primary goal in redrawing these sheets was to create a dedicated "GPIO view". This gives a single-sheet, pin-centric reference for the STM32H5E5ZJT6 hardware mapping on the ST NUCLEO-H5E5ZJ PCB.

Regarding debugging:

The main sheet (5e5_main_v2.pdf) captures the standard CN4 (MIPI-20) debug header for external debuggers (like an ST-LINK/V3SET or J-Link). It also includes the NUCLEO-H5E5ZJ user USB-C, and the Ethernet PHY with CN14 RJ45 connector.

The second sheet (5e5_stlink.pdf) documents the on-board ST-LINK V3 circuit as implemented on the ST NUCLEO board.

Having both redrawn with an alternative focus on GPIO availability helps quickly identify all physical port allocations and multiplexing trade-offs.

A few practical examples:

Peripheral Pin Sharing: If I want to use all three FDCAN controllers, it's instantly clear if that's possible or if it conflicts with pins used by say the Ethernet PHY.

Reclaiming Debug GPIOs: If an application moves beyond the need for the onboard ST-LINK, placing the ST-LINK MCU into reset via the onboard jumper frees up four GPIO lines (which are also routed out to expansion headers) for the main application.

Custom M.2 Expansion: If an application doesn't require a serial memory card in the M.2 Key-A socket, it makes it straightforward to design a custom daughterboard that plugs into CN19 to tap into those high-speed signals and GPIOs.

[mƎALLEm]

Hello ​@rich.g.williams ,

Thank you for the sharing and for your contribution.

[rich.g.williams]

​@mƎALLEm   You are very welcome.

[rich.g.williams]

Thanks for your comments. Yes cross-checked many times by comparing netlists and visually. Mistakes now are highly unlikely but not impossible.  As my work progresses I will make "overlay" like what they called skins, for specific configurations then merge the skins into one pdf for easy access - just by renaming ports.

I know that ST Cube MX and IDE give an IC graphic to help. But still allocating and rearranging alternates to pins and ports on STM32H5E5 is far from easy.

Richard 

[rich.g.williams]

Since starting this thread I have drafted a second skin version of 5e5_main_v2.pdf and it is attached. It is a skin for the startup code listed on this thread:-

STM32H5E5ZJ Startup Test Code

5e5_skin1.pdf exposes SPI1 connections, MCO1 and MCO2 connections intended for test purposes and later on for using SPI1 as a custom monitor.

Any comments and suggestions much appreciated.