Skip to main content
Associate
April 9, 2026
Question

ST67W611M1 QConn_Flash failure

  • April 9, 2026
  • 4 replies
  • 213 views

Dear all,

I have designed a custom board using the STM32H563ZIT6 as the host MCU and the ST67W611M1 as the NCP.

As part of the initial bring-up, I am attempting to flash the ST67W611M1 using the QConn_Flash_Cmd-ubuntu tool in standalone mode. For this, I have connected a USB-to-TTL converter directly to the NCP UART interface.

The BOOT and CHIP_EN pins of the ST67 are controlled by the host MCU, which toggles them in the required sequence to place the NCP into UART (flash) mode (see below code). I use the same sequence given in the NCP_Loader Example.

if (flash)
 {
 LL_GPIO_SetOutputPin(BOOT_GPIO_Port, BOOT_Pin);
 }
 else
 {
 LL_GPIO_ResetOutputPin(BOOT_GPIO_Port, BOOT_Pin);
 }

 /* RESET NCP CHIP */
 LL_GPIO_ResetOutputPin(CHIP_EN_GPIO_Port, CHIP_EN_Pin);
 HAL_Delay(100);
 LL_GPIO_SetOutputPin(CHIP_EN_GPIO_Port, CHIP_EN_Pin);

 if (flash)
 {
 /* CLEAR BOOT */
 HAL_Delay(100);
 LL_GPIO_ResetOutputPin(BOOT_GPIO_Port, BOOT_Pin);
 }

I verified the BOOT and CHIP_EN signals on an oscilloscope, and they appear to follow the expected sequence. However, when I run the QConn_Flash_Cmd-ubuntu tool to flash the Mission 1 or 2 binary, the process fails during the handshake phase with the NCP. The tool reports the following output:

❯ ./QConn_Flash/QConn_Flash_Cmd-ubuntu --port /dev/ttyUSB0 --config ./NCP_Binaries/mission_t02_flash_prog_cfg.ini --efuse NCP_Binaries/efusedata.bin
[17:46:22.644] - Serial port is /dev/ttyUSB0
[17:46:22.644] - ==================================================
[17:46:22.645] - FW get address from partiton file /home/gandhi/STM32Cube/Repository/Packs/STMicroelectronics/X-CUBE-ST67W61/1.2.0/Projects/ST67W6X_Scripts/Binaries/NCP_Binaries/./partition.bin
[17:46:22.645] - Address=0x10000
[17:46:22.645] - FW get size from partiton file /home/gandhi/STM32Cube/Repository/Packs/STMicroelectronics/X-CUBE-ST67W61/1.2.0/Projects/ST67W6X_Scripts/Binaries/NCP_Binaries/./partition.bin
[17:46:22.645] - Size=1785856
[17:46:22.646] - Program Start
[17:46:22.646] - ========= eflash loader cmd arguments =========
[17:46:22.647] - serial port is /dev/ttyUSB0
[17:46:22.647] - cpu_reset=False
[17:46:22.854] - com speed: 2000000
[17:46:22.854] - ========= Interface is uart =========
[17:46:22.855] - Bootrom load
[17:46:22.855] - ========= get_boot_info =========
[17:46:22.855] - ========= image get bootinfo =========
[17:46:23.108] - tx rx and power off, press the machine!
[17:46:23.108] - cutoff time is 0.05
[17:46:23.158] - power on tx and rx
[17:46:24.063] - reset cnt: 0, reset hold: 0.05, shake hand delay: 0.1
[17:46:24.063] - clean buf
[17:46:24.064] - send sync
[17:46:24.165] - ack is b''
[17:46:24.165] - retry
[17:46:24.416] - tx rx and power off, press the machine!
[17:46:24.416] - cutoff time is 0.05
[17:46:24.467] - power on tx and rx
[17:46:25.372] - reset cnt: 0, reset hold: 0.05, shake hand delay: 0.1
[17:46:25.372] - clean buf
[17:46:25.372] - send sync
[17:46:25.473] - ack is b''
[17:46:25.474] - retry
[17:46:25.725] - tx rx and power off, press the machine!
[17:46:25.725] - cutoff time is 0.05
[17:46:25.775] - power on tx and rx
[17:46:26.680] - reset cnt: 0, reset hold: 0.05, shake hand delay: 0.1
[17:46:26.680] - clean buf
[17:46:26.680] - send sync
[17:46:26.781] - ack is b''
[17:46:26.781] - retry
[17:46:26.781] - shake hand fail
[17:46:26.781] - shake hand fail
[17:46:26.782] - ========= ChipID: =========
[17:46:26.782] - Get bootinfo time cost(ms): 3927.554443359375
[17:46:26.782] - {"ErrorCode": "0050","ErrorMsg":"CHIP IMG LOAD SHAKEHAND FAIL"}
[17:46:26.782] - Burn Retry
[17:46:26.782] - Burn return with retry fail

Any help is greatly appreciated!

Thanks a lot!

4 replies

Associate III
January 14, 2026

I am using STM32H723ZGT6 as the host MCU with the ST67W611M1 Wi-Fi + BLE module.

Software details:

Firmware flashed on ST67: T01 binary

STM32 firmware package: X-CUBE-ST67W61(1.1.0)

Application selected: BLE P2P

Enabled parameters:

Wi-Fi SAP: Yes

Wi-Fi STA: Yes

BLE: Yes

NET: Yes

DHCP: STA+SAP

Issues observed:

Intermittent failure after reset in debug mode

When I reset the board while running in debug mode, the system sometimes does not work correctly(w6x init failed or other intiliazation failed in mainapp.c). The behavior is inconsistent—occasionally it works, but often it fails after reset.

 

Wi-Fi SoftAP start failure

The following API fails:

ret = W6X_WiFi_StartAp(&ap_config);

While debugging, the failure occurs due to a timeout in the following function:

/* Initialize the dual interface mode */

ret = TranslateErrorStatus(W61_WiFi_SetDualMode(p_DrvObj));

SPI clock configuration doubt

Could you please confirm the recommended SPI clock frequency for STM32H723ZGT6 when interfacing with ST67W611M1?

Should it be 40 MHz, or is a lower frequency required for stable operation?

DMA and linker script configuration

Is it necessary to modify the linker script for STM32H723ZGT6 to support DMA buffers (for example, placing buffers in non-cacheable memory)?

Could incorrect cache/DMA memory configuration cause the above intermittent failures or timeouts?

I have configured the board according to the document “How to use the X-CUBE-ST67W61 software package”, but the issue still persists.

Please let me know if any additional configuration, firmware version, or hardware constraint needs to be considered.

i attached the corresponding .ioc and mainapp.c files.

Thank you for your support.

 

Andrew Neil
Super User
April 9, 2026
Associate
April 24, 2026

We faced similar problems; it turned out that USB/TTL converter matters. Have you tried a different one?
It looks like the UART interface in this module is very "fussy" in this regard (timing issues?).
We tested a few models; some were unstable (50/50), some didn't work at all.
We ended up using the FTDI FT232RL, which works reliably.

Louis AUDOLY
ST Employee
May 7, 2026

Hello  @Aashritha_Vuda ,

Thanks for pointing out this issue and sorry for the late reply.

This is not an SPI clock configuration issue but a memory shortage on the ST67 with T01 binary. We are working on providing a more complete description of the root cause of this issue.


In the meantime, I recommend you to switch to a T02 binary flashed on the ST67.
As the LwIP stack is moved to the STM32 host, this leaves more space on the ST67 to handle more complex use cases, with STA, soft-AP and BLE working in the same time.

I hope this will help

Regards
Louis