STM32U5G9 HSPI1: Only 2 of 4 QSPI data lines active during pixel write
Only 2 of 4 QSPI data lines active during pixel write, despite DMODE=3 confirmed in CCR
이미지 4장을 모두 참조하여 ST Community 문의 글을 작성합니다.
Environment
- MCU: STM32U5G9ZJ (Cortex-M33, TrustZone enabled)
- IDE: STM32CubeIDE
- HAL version: STM32U5xx HAL Driver (included in project)
- Interface: HSPI1 → QSPI LCD (ICNA3306-compatible controller)
Hardware Configuration
GPIO settings are shown in [XSPI_2.png]. All six HSPI1 pins are configured as Alternate Function Push-Pull with GPIO_SPEED_FREQ_VERY_HIGH and GPIO_AF8_HSPI1:
Pin Signal Speed| PI3 | HSPI1_CLK | Very High |
| PH9 | HSPI1_NCS | Very High |
| PH10 | HSPI1_IO0 | Very High |
| PH11 | HSPI1_IO1 | Very High |
| PH12 | HSPI1_IO2 | Very High |
| PH13 | HSPI1_IO3 | Very High |
Clock configuration is shown in [XSPI_3.png]: HSPI1 kernel clock source is set to SYSCLK (160 MHz). PLL1: HSE(16MHz) × PLLN(10) / PLLR(1) = 160 MHz.
CubeMX parameter settings are shown in [XSPI_1.png]:
- Fifo Threshold: 4 bytes
- Memory Type: Micron
- Clock Prescaler: 1 (→ FCLK = 80 MHz)
- Clock Mode: Low (Mode 0)
- Sample Shifting: Half Cycle
Problem Description
I am trying to write a full-frame image (194×368, RGB565 = 142,784 bytes) to the LCD using HSPI1 in indirect write mode with 4-line data (quad SPI).
The pixel write command uses instruction 0x32 with a 24-bit address 0x002C00 (encoding the RAMWR command 0x2C), and DataMode = HAL_XSPI_DATA_4_LINES, as shown:
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE; sCommand.Instruction = 0x32; sCommand.AddressMode = HAL_XSPI_ADDRESS_1_LINE; sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS; sCommand.Address = 0x002C00; sCommand.DataMode = HAL_XSPI_DATA_4_LINES; // ← intended quad sCommand.DataLength = totalBytes; // 142784 sCommand.DummyCycles = 0; sCommand.DQSMode = HAL_XSPI_DQS_DISABLE; sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
Oscilloscope measurement shows that only IO0 and IO1 carry data. IO2 and IO3 remain at constant levels (IO2 = constant LOW, IO3 = constant LOW) throughout the entire data phase.
What I Have Verified
I read the HSPI1->CCR register immediately after HAL_XSPI_Command() returns and confirmed:
HSPI1->CCR = 0x03002101 Breakdown: bits [2:0] = 001 → IMODE = 1-LINE ✓ bits [10:8] = 001 → ADMODE = 1-LINE ✓ bits [13:12] = 10 → ADSIZE = 24-bit ✓ bits [26:24] = 011 → DMODE = 4-LINES ✓ bit [30] = 0 → SIOO = INST_EVERY_CMD ✓
DMODE is confirmed as 3 (quad) in the hardware register. The STM32 HSPI peripheral should therefore be driving all four IO pins as outputs during the data phase. However, the oscilloscope consistently shows only IO0 and IO1 toggling.
I also verified:
- All HSPI GPIO pins are physically connected to the LCD (PCB continuity confirmed)
- LCD is initialized with 0xC4 = 0x80 to enable DSPI mode before the pixel write
- HAL_XSPI_Command() returns HAL_OK
- Image buffer is 4-byte aligned and located in SRAM (static variable)
Questions
If DMODE = 3 (quad) is confirmed in HSPI_CCR, is it possible for the HSPI peripheral to still output only 2 data lines? Is there any other register (e.g., MSEL in CR, or a DLL calibration state) that could gate IO2/IO3?
The LCD is initialized with 0xC4 = 0x80 ("DSPI mode enable" per the LCD vendor's initialization sequence). Could this register value be enabling only 2-wire (dual) mode on the LCD side, causing IO2/IO3 to be driven to fixed levels by the LCD controller and contending with the STM32? If so, what value of 0xC4 enables true 4-wire (quad) mode?
In indirect write mode (FMODE=00) with ADMODE≠0 and DMODE≠0, RM0456 states that the transfer is triggered by the first write to HSPI_DR — not HSPI_AR. Is this correct? If so, does the FTF flag in HSPI_SR behave normally (set when FIFO has free space) before the first DR write, or is FTF only meaningful after the transfer has been triggered?
Any guidance would be greatly appreciated. Thank you.