Skip to main content
Associate
April 9, 2026
Question

ST67W611M1 QConn_Flash failure

  • April 9, 2026
  • 2 replies
  • 108 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!

2 replies

Andrew Neil
Super User
April 9, 2026
A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
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.