I am porting the ST67W611M1 WiFi/BLE driver (X-CUBE-ST67W61 v1.2.0) from a NUCLEO-U575ZI-Q to a custom PCB with STM32F767VIT6. The Nucleo version works perfectly. On the F767 custom board, W6X_Init() hangs indefinitely.
HARDWARE
- Host MCU: STM32F767VIT6 (216MHz, Cortex-M7)
- WiFi module: ST67W611M1 (NCP firmware: mission_t01_v2.0.97.bin — confirmed flashed and verified)
- SPI2: PB12=NSS(SW), PB13=SCK, PB14=MISO, PB15=MOSI
- CHIP_EN: PD4, SPI_RDY: PD7 (EXTI rising+falling, NVIC enabled)
- DMA1 Stream3 (RX, CH0), Stream4 (TX, CH0)
- FreeRTOS heap: 102400, configMAX_PRIORITIES: 56
- LOW_POWER_MODE: disabled, W6X_CLOCK_MODE: 1 (internal RC)
SYMPTOMS
PuTTY output stops at:
W6X_Init...
[hangs forever]
W6X_Init() never returns. The FreeRTOS task blocks on sem_if_ready permanently.
DEBUG FINDINGS
I added debug prints to spi_port_transfer_dma() to log RX buffer contents. Here is what the module sends during init:
RX[0]=0D [1]=0A [2]=72 len=12 → "\r\nr..." (boot message start)
RX[0]=AA [1]=55 [2]=00 len=12 → SPI header
RX[0]=2B [1]=43 [2]=57 len=16 → "+CW..."
RX[0]=2B [1]=47 [2]=45 len=16 → "+GE..."
RX[0]=41 [1]=54 [2]=20 len=256 → "AT ..." (AT command exchange)
RX[0]=2B [1]=56 [2]=42 len=12 → "+VB..." (version/boot info)
RX[0]=2B [1]=45 [2]=46 len=12 → "+EF..." (EFUSE reads begin, loop forever)
The module IS responding. DMA completes every transaction (HAL_SPI_TxRxCpltCallback fires). The driver progresses through GetModuleInfo (reads GMR, VBAT, EFUSE) but sem_if_ready is never posted and W6X_Init never returns.
WHAT I HAVE TRIED
- Verified EXTI9_5 NVIC enabled for PD7
- DMA IRQ handlers present and calling HAL_DMA_IRQHandler
- Tried blocking SPI (HAL_SPI_TransmitReceive) — same hang
- Tried DMA (HAL_SPI_TransmitReceive_DMA) — DMA completes but still hangs
- Disabled D-Cache and I-Cache (SCB_DisableDCache/SCB_DisableICache) — no change
- configMAX_PRIORITIES=56 (above SPI engine task priority of 53)
- Removed all UART debug prints from ISR/callback context
- W6X_POWER_SAVE_AUTO=0, W6X_CLOCK_MODE=1
- NCP firmware reflashed and verified via NCP_get_chip_info.bat — chip info reads successfully
QUESTION
What is different about the STM32F767 that would prevent sem_if_ready from being posted? The SPI data exchange appears correct — the module is sending valid responses. Is there a known issue with the modem command handler parser on Cortex-M7, or a specific spi_port.c adaptation required for F767?
Any guidance appreciated. Happy to provide more debug output or code snippets.
Thank you.
