cancel
Showing results for 
Search instead for 
Did you mean: 

ST67W611M1 QConn_Flash failure

KushalGandhi108
Associate II

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 2
Andrew Neil
Super User

Similar: Unable to bring up ST67 ?

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.
SlawekN
Associate

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.