Skip to main content
김형건
Associate II
September 29, 2026
Solved

ST67W611M1A6BTR – Are BOOT and UART required when using the factory firmware without modification?

  • September 29, 2026
  • 1 reply
  • 26 views

Title: ST67W611M1A6BTR – Are BOOT and UART required when using the factory firmware without modification?

Hello,

I am designing a custom board using an STM32G474 as the host MCU and an ST67W611M1A6BTR as the Wi-Fi/Bluetooth network coprocessor.

I intend to use the standard X-CUBE-ST67W61 software and communicate with the module through the SPI/AT interface. I do not intend to develop or debug custom firmware running inside the QCC743 SoC.

After reviewing the ST67W611M1 datasheet, the B2413 reference schematic, AN6316, and the ST hardware setup wiki, I would like to clarify the required programming and debug connections.

In the B2413 schematic, module pins 1 to 4 are shown as:

  • Pin 1: JTMS

  • Pin 2: JTCK

  • Pin 3: BOOT_WW6 / JTDO

  • Pin 4: JTDI

However, in the ST67W611M1 datasheet, pins 1, 2, and 4 are marked as RESERVED and are required to be left unconnected for the A6B/A6U variants.

My questions are as follows:

  1. Does every production ST67W611M1A6BTR module contain a usable mission firmware image when shipped?

  2. If a mission firmware image is already installed, can it be used without performing an initial update using QConn_Flash? Is the preinstalled firmware version and T01/T02 profile guaranteed?

  3. In which cases is reprogramming or updating the ST67W611M1 firmware required or recommended? For example:

    • Selecting between the T01 and T02 mission profiles

    • Matching a particular X-CUBE-ST67W61 version

    • Applying security or bug fixes

    • Adding new Wi-Fi or Bluetooth features

    • Running manufacturing/RF tests

    • Recovering from corrupted firmware

  4. If I do not require low-level debugging of the QCC743 SoC, should pins 1, 2, and 4 simply be left completely unconnected, as specified in the datasheet?

  5. The ST wiki states that the BOOT pin should be controlled directly by the host MCU. If I intend to operate only in normal Flash mode, can BOOT be permanently held low, or is host control still recommended for initial programming and recovery?

  6. Should UART_TX and UART_RX always be connected to the host MCU, or would accessible test points be sufficient for production programming and recovery?

  7. Are normal product settings such as Wi-Fi credentials, country code, SoftAP configuration, and Bluetooth parameters configured through the SPI/AT interface without requiring BOOT mode, JTAG, or module firmware reprogramming?

My current proposed implementation is:

  • Pins 1, 2, and 4: NC

  • Pin 3 BOOT: Connected to an STM32 GPIO

  • CHIP_EN: Connected to an STM32 GPIO

  • UART_TX/RX: Connected to the STM32 UART and/or accessible test points

  • SPI, SPI_RDY, and SPI_CS: Used for normal runtime communication

  • No external JTAG connector for the ST67W611M1

Could you please confirm whether this is the recommended implementation for a production board?

I would also appreciate any recommendation regarding the default BOOT state, pull resistor, and required CHIP_EN/BOOT power-up sequence.

Thank you.

Best answer by EPASZ.1

Hello,

generally, the modules come from factory with FW 2.0.89 T01, related to X-CUBE version 1.1.0. This can be updated using the PC tool (through the module’s UART pins) or from the host’s OTA function (via SPI). As described here Wiki. So you do not 100% need UART for updating.

However, for RF testing (which is mandatory for end-products), UART is needed to control the module from a PC tool as described in Wiki. And when you load the manufacturing binary for RF testing, you will no longer have access to SPI update. So you will again need UART to change to mission binary.

  1. Yes
  2. Technically yes, but we do strongly recommend to update the FW to the latest available version.
  3. All of those, except for “recovery”. There should not be any way to “corrupt” the FW in normal operation. At most, a reboot might be needed. Failed FW update can cause corruption of the new FW image, but recovery is handled by the module’s internal bootloader.
  4. Debug is disabled on the module - you should not be able to use those pins anyway. So left floating is the correct way.
  5. I’d recommend setting up a test point on the PCB so you can access it by an external probe when performing eg the RF testing. Having it connected to the host MCU is OK, but it seems easier to control it externally when going through testing (and the host MCU can be even powered off).
  6. Test points should be ok, as above
  7. Yes, all those are handled through SPI/AT layer. 

Yes, the connections are good. The only requirement for the BOOT state is to be set (high or low) before the rising edge of CHIP_EN. We don’t have any specific timing requirements on that or related to power on (except what is in DS, part 4.4), unfortunately.

1 reply

EPASZ.1
EPASZ.1Best answer
ST Employee
September 29, 2026

Hello,

generally, the modules come from factory with FW 2.0.89 T01, related to X-CUBE version 1.1.0. This can be updated using the PC tool (through the module’s UART pins) or from the host’s OTA function (via SPI). As described here Wiki. So you do not 100% need UART for updating.

However, for RF testing (which is mandatory for end-products), UART is needed to control the module from a PC tool as described in Wiki. And when you load the manufacturing binary for RF testing, you will no longer have access to SPI update. So you will again need UART to change to mission binary.

  1. Yes
  2. Technically yes, but we do strongly recommend to update the FW to the latest available version.
  3. All of those, except for “recovery”. There should not be any way to “corrupt” the FW in normal operation. At most, a reboot might be needed. Failed FW update can cause corruption of the new FW image, but recovery is handled by the module’s internal bootloader.
  4. Debug is disabled on the module - you should not be able to use those pins anyway. So left floating is the correct way.
  5. I’d recommend setting up a test point on the PCB so you can access it by an external probe when performing eg the RF testing. Having it connected to the host MCU is OK, but it seems easier to control it externally when going through testing (and the host MCU can be even powered off).
  6. Test points should be ok, as above
  7. Yes, all those are handled through SPI/AT layer. 

Yes, the connections are good. The only requirement for the BOOT state is to be set (high or low) before the rising edge of CHIP_EN. We don’t have any specific timing requirements on that or related to power on (except what is in DS, part 4.4), unfortunately.

Terms & ConditionsAccessibility statement