2026-01-29 1:14 AM - edited 2026-01-29 1:26 AM
Hello,
I am using an ST7701S LCD over 3-wire SPI (CS, SCK, SDA) with my STM32.
When I send the initialization commands from my ESP, I noticed the following:
The first command of the sequence is not sent.
The program seems to stop at the second stage, around the 100th command.
SPI is configured in master mode, polling (no DMA, no interrupts).
Example of the write function:
void ST7701_Write(uint8_t dc, uint8_t data) {
uint16_t value = ((dc & 0x01) << 8) | data;
HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi2, (uint8_t *)&value, 1, HAL_MAX_DELAY);
HAL_GPIO_WritePin(LCD_CS_GPIO_Port, LCD_CS_Pin, GPIO_PIN_SET);
}Questions:
Could the first command being skipped be due to HAL/SPI initialization or state?
What is the recommended method to ensure all commands are reliably sent over 3-wire SPI to ST7701S?
Thank you for your help.
Solved! Go to Solution.
2026-01-29 7:12 AM - edited 2026-01-29 7:12 AM
What is the role of the ESP32 in all this?
What happens if you remove it?
2026-01-29 9:39 AM - edited 2026-01-29 10:15 AM
There's no reason why the first call to ST7701_Write would not happen. Even if the HAL SPI call doesn't work, the CS toggle would still happen. There's something else going on here, perhaps the code running is different than the code presented, maybe your run configuration isn't what you think it is.
Perhaps remove the delays and show the full capture starting from the CS pulse during ST7701S Reset.
2026-01-29 10:26 AM - edited 2026-01-29 10:29 AM
> after HAL_Delay() no more SPI activity is observed on the bus.
In the presented code, you have a HAL_Delay before any of the SPI activity. It would hang there if interrupts or ticks weren't working correctly or if HAL_Delay was hanging for some reason. This story just isn't adding up. Recheck your assumptions.
> What is the role of the ESP32 in all this?
+1
ESP32 is totally unrelated to STM32. What are you actually running on? Why is ESP32 mentioned?