SPI reads all returning 0xFF — logic analyser shows MISO activity, W25Q32 not responding to commands

You can confirm exactly which mode is correct using the existing Saleae capture, without touching the firmware.

Open the SPI async decoder on your capture and try changing only the Clock Phase setting (CPHA in the decoder). When the decoded MISO bytes change from 0xFF 0xFF 0xFF to 0xEF 0x40 0x16, that's the mode the flash is actually talking. Then you match the firmware to what the decoder confirmed, not the other way around.

Two things to look at in the raw waveform to orient yourself:

SCK idle state: Is SCK low when CS is high? That's CPOL=0. SCK idle high means CPOL=1. W25Q32 supports both, so either is valid — but your STM32 init must match.

MISO transition timing: Zoom in on a single bit period. The W25Q32 drives MISO after the falling edge of SCK and holds it through the next rising edge. In a correct Mode 0 capture, MISO should be rock-solid when SCK goes high — that's your sampling moment. If MISO is visibly transitioning right at the SCK rising edge instead of being stable there, the flash is outputting for Mode 0 but your MCU is set to Mode 1 and sampling half a cycle off. That's when you get 0xFF.

Adjust the decoder first. Match the firmware to the confirmed mode. Saves you another firmware iteration in the dark. If you're new to logic analyser capture setups, logic analyser vs oscilloscope covers SPI multi-channel trigger configuration and what to look for in the capture.

Even if CubeMX looks right, check the generated init code directly. The STM32 HAL and CubeMX peripheral guide covers what each field in the SPI init struct does — but specifically, find MX_SPI1_Init (or whichever peripheral) and verify it actually says:

hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi1.Init.CLKPhase    = SPI_PHASE_1EDGE;

CubeMX regenerates this on every .ioc save, so if your source and .ioc got out of step, the screen and the binary can disagree. SPI_PHASE_1EDGE is Mode 0. SPI_PHASE_2EDGE is Mode 1. That's the field to find.

Also check hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB. The W25Q32 is MSB-first. If this is set to LSB, the command byte 0x9F gets transmitted as 0xF9, which the flash doesn't recognise. It would still clock something out on MISO — probably zeros or garbage from an unrecognised command — which would explain the MISO activity without getting a valid JEDEC ID back.

Last thing worth checking: HAL_SPI_GetState. If the peripheral is sitting in an error state (MODF, for example), every HAL_SPI_TransmitReceive call silently fails and returns the transmit buffer contents on the receive side. MODF fires when hardware NSS detects a low level while the peripheral thinks it's master. If you've got the hardware NSS pin floating or accidentally shorted, that can corrupt every transaction without logging anything obvious. Confirm HAL_SPI_GetState returns HAL_SPI_STATE_READY before the call.