This documentation covers a STM32 Nucleo-H753ZI tutorial project that reads and writes a Winbond W25Q-series NOR flash chip – the Adafruit 5632/5633/5634 QSPI DIP breakout boards – over the STM32's dedicated QUADSPI peripheral, with hardware-managed chip select and a destructive validation test suite ported from the companion SPI project for confirming correctness on real hardware.

Project Overview

The firmware demonstrates:

STM32H753ZI peripheral setup generated by STM32CubeMX, including Cortex-M7 D-Cache disabled – required for QUADSPI safety on this core
QUADSPI indirect-mode communication with a Winbond W25Q flash chip, single-line instruction/address/data phases
Hardware-managed NCS (PB10) instead of a manual GPIO, and why that's the correct choice here – QUADSPI's peripheral natively understands a command's instruction/address/dummy-cycle/data phase structure via a single QSPI_CommandTypeDef, unlike generic SPI hardware
Reset and JEDEC ID identification (W25QFlashQSPI::Init())
Sector erase, buffered write with internal page-boundary splitting, and buffered read
A fail-hard-at-Init()-but-propagate-elsewhere error handling policy, backed by a configurable per-transaction QUADSPI timeout
A destructive validation test suite covering erased-state verification, a small-range smoke test, a 20-pattern stuck-at/ bit-coupling test, and a page-boundary write test
The C/C++ bridge pattern used to call C++ driver code from CubeMX's plain-C main.c

Project-Level Documentation

W25QFlashQSPI – the QUADSPI driver class
W25QValidation – the destructive validation test suite
entryPointCPP.hpp – the extern "C" bridge into main.c

Relationship to the companion SPI project

This project is a standalone counterpart to H753_CPP_W25Q_SPI_Flash_Read_Write_01, not a fork of it – see that project's own history for why (SPI and QUADSPI are different peripherals with a genuinely different command model, not "the same driver with more pins"). w25q_commands.h is shared verbatim between the two (transport-agnostic JEDEC opcodes and chip geometry), and W25QFlashQSPI keeps the same public API shape as W25QFlashSPI on purpose, but the private implementation and the chip-select strategy are unrelated internally.

Architectural Direction

This project's documentation is intentionally a single mainpage rather than the multi-page/@defgroup layered structure used by larger projects – one driver class plus one validation suite doesn't need that much subdivision. See W25QFlashQSPI.hpp's and w25q_validation.hpp's own file-level comments for the detailed design rationale.