ST67W611M1 Not Waking Up After T01 Firmware Flash - SPI_RDY Remains Low

[hrishikeshmanjarekar]

Hi ST team,

I am currently evaluating the ST67W611M1 Wi-Fi module in NCP mode and am facing an issue where the module does not appear to boot correctly after firmware programming.

Hardware Setup

• Module: ST67W611M1
• Supply Voltage: 3.3V
• CHIP_EN: Driven High (3.3V)
• BOOT pin: Connected to GND (Normal Boot Mode)
• SPI_CS: Held High
• Firmware: T01 mission firmware (st67w611m_mission_t01_v2.0.106.bin)
• Programming Method: Standalone firmware download using USB-to-TTL UART
• Host MCU:  STEVAL STWINBX1 Development kit. (STM32U585)

Issue

After powering the module:

1. CHIP_EN goes high correctly.
2. BOOT remains low.
3. Supply is stable at 3.3V.
4. However, SPI_RDY never asserts high.
5. I also do not see any activity on the SPI_RDY pin using an oscilloscope.
6. Because SPI_RDY never goes high, the host cannot proceed with SPI communication.

Verification Already Performed

SPI Signals

I have verified:

• SPI_CLK
• SPI_MOSI
• SPI_MISO
• SPI_CS

SPI Configuration: 

• Baud rate: 5 MBits/s and 2.5 MBits/s
• SPI Mode: 0
• SPI Port: SPI2 on STM32U585
• ReadyMasterManagement - SPI_RDY_MASTER_MANAGEMENT_INTERNALLY

Signal routing and GPIO configuration on the STM32 side appear correct.

Oscilloscope Observation

The attached scope capture shows:

• CH1 (Yellow): CHIP_EN transitions high and remains high.
• CH2 (Blue):  SPI_RDY remains low and never toggles.

Additional Checks

• Performed multiple power cycles after flashing.
• Confirmed BOOT pin is low during power-up.
• Confirmed 3.3V supply is present and stable.
• Measured approximately 1.76V on the 32K_OUT pin and observed a frequency around 1.248 kHz, which seemed unusual.
• SPI_CS kept high while waiting for the device to complete boot.

Questions

1. After successfully flashing the T01 mission firmware (st67w611m_mission_t01_v2.0.106.bin), should SPI_RDY automatically go high after power-up?
2. Is SPI_RDY dependent on any host-side SPI initialization sequence, or should it rise independently once the module boots?
3. Is there any way to confirm that the T01 firmware has booted correctly through UART logs or another status pin?
4. Does the observed behavior on the 32K_OUT pin indicate that the firmware is not booting correctly?
5. Are there any mandatory pin states, reset timing requirements, or power-up sequences beyond:
   • BOOT = Low
   • CHIP_EN = High
   • SPI_CS = High
   • 3.3V Supply
6. Is there a recommended standalone test procedure to verify the module has booted before integrating the full ST67 middleware?

Any guidance on how to determine whether the issue is related to firmware boot, hardware configuration, SPI_RDY behavior, or power sequencing would be greatly appreciated.

Thank you.

[EPASZ.1]

One thing that stands out to me is that you say “SPI_CS kept high...” - typically, the CS pin is not actually held high during initialization. After starting the module (via CHIP_EN going high), its SW will initialize and it will make the first transfer from its side. You can see a capture of this on wiki.

I’m not sure how the module would behave if the CS was already high before the first transfer as this does not conform to the “module → host” direction but is instead the opposite “host → module”.

For the HW part, are you using a stand-alone module on your own PCB, or the X-Nucleo shied? As you say, the 32K_OUT frequency does not seem correct - but this should be generated by the LSE crystal on PCB (or provided from the host).

[hrishikeshmanjarekar]

Hi,

Thank you for the feedback.

To clarify my setup:

• I am using a X-NUCLEO ST67W611M1 expansion board with Steval STWINBX1 development board.
• The T01 mission firmware was programmed using the standalone UART (USB-to-TTL) flashing method.
• During power-up:
  • VDD = 3.3V
  • BOOT = GND
  • CHIP_EN transitions from Low to High
  • SPI_CS is driven by the host MCU and remains High after reset
  • SPI_RDY remains Low permanently

Regarding SPI_CS, my understanding from the documentation was that the host should keep CS inactive until the module requests an SPI transfer through SPI_RDY. Since SPI_RDY never asserts, no SPI transaction is started from either side.

Could you please clarify:

1. Should SPI_CS be left floating/input or driven Low/High during the initial boot phase before SPI_RDY is asserted?
2. Is SPI_RDY expected to go High solely after a successful module boot, independent of any host SPI activity?
3. Is there any UART boot log or other signal that can be monitored to confirm that the T01 firmware has started successfully?

Regarding the clock:

I measured approximately 1.248 kHz on 32K_OUT, whereas I expected a 32.768 kHz clock. This makes me suspect that the module firmware may not be booting correctly.

Could you confirm:

• Does ST67W611M1 require an external 32.768 kHz source when used as a standalone module?
• Should 32K_OUT output a valid 32.768 kHz clock after a successful boot?
• If the 32K_OUT frequency is incorrect, would SPI_RDY remain low as a consequence of the failed initialization?

At this point, my main concern is determining whether the issue is:

• an incorrect boot sequence,
• a missing/invalid low-speed clock,
• an unsuccessful T01 firmware flash,
• or a hardware startup problem.

I also attached the flashing logs in cli.

Any guidance on the expected pin states (CHIP_EN, BOOT, SPI_RDY, SPI_CS, and 32K_OUT) immediately after power-up would be greatly appreciated.

Thank you.

[hrishikeshmanjarekar]

Hello,

I am using an ST67W611M1 T01 Wi-Fi module and flashing it through a USB-to-TTL converter using QConn_Flash_Cmd.exe.

I tested two different flashing configurations, and I am seeing different behaviors.

Hardware and software setup

• Module: ST67W611M1
• Firmware architecture: T01
• Firmware version: 2.0.106
• Firmware image: spi_wifi_qcc74xdk
• Boot2 version: 8.1.9
• USB-to-TTL UART port: COM10
• Module BOOT pin: High during flashing
• Flash tool: QConn_Flash_Cmd.exe
• Firmware build time shown in the boot log: Mar 20 2026 09:30:18

Test 1: Flashing with mission_t01_flash_prog_cfg.ini

Command used:

QConn_Flash\QConn_Flash_Cmd.exe --port COM10 --baudrate 115200 --config NCP_Binaries\mission_t01_flash_prog_cfg.ini

After flashing with this configuration, Boot2 cannot find a valid application image.

The important log messages are:

Active PT:0,Age 160

R header from 10000

Encrypt mode:0

Sign mode:0

Group 0 parse fail ret 0x206

Group roll back

Boot return 0x21c

Active PT:1,Age 161

R header from 1c4000

Group 0 parse fail ret 0x204

no valid group found

Media boot return 539

Boot2 fail

 

This sequence repeats continuously.

It appears that neither firmware partition contains an image that Boot2 can successfully parse.

 

Test 2: Flashing with mission_t01_flash_prog_cfg.ini and efusedata.bin

Command used:

QConn_Flash_Cmd.exe --port COM10 --baudrate 921600 --config NCP_Binaries\mission_t01_flash_prog_cfg.ini --efuse=NCP_Binaries\efusedata.bin

With this configuration, the application image is found and verified successfully.

The boot log shows:

Active PT:0,Age 0

R header from 10000

Encrypt mode:0

Sign mode:1

R PK

R SIG1

Cal hash addr 0x11000,len 1484928

Hash Success

Check sig1

Sign suss,Time=72 ms

group[0] offset 11000 ,core[0] offset 0 bootentry a0000000

The application also starts successfully:

 

Build:09:30:28,Mar 20 2026

Version: component_version_sdk_2.0.106

Version: SW image:spi_wifi_qcc74xdk

app version in efuse is: 0

app version in application is: 0, not less than app version in efuse, the application should run up

dynamic memory init success, ocram heap size = 124 Kbyte

board init done

 

The partition table also appears valid:

magicCode 0x54504642

entryCnt 8

crc32 0xE38928F3

Boot2 Address 0x00000000

FW Address 0x00010000 / 0x001c4000

media Address 0x00378000

PSM Address 0x003e9000

MFD Address 0x003ff000

 

However, the module resets while printing the RF parameter initialization logs. The output is interrupted at approximately this point:

rfparam>>country_code = WW

rfparam>>en_tcap = 0

rfparam>>tcap_tsen[10-4,20,39,39,40,41,42,43,44,

rfparam>>tcap_cap[11]: 28,29,30,31,32,33,34,35,36,…

 

Immediately after that, Boot2 starts again:

custom 0x0

flash init 0

Boot2 start:Apr 11 2025,11:39:40

 

The same boot sequence then repeats.

I also noticed that the following counter increases on each reboot:

Counter value=254

Counter value=255

 

This suggests that the application is rebooting repeatedly rather than the UART terminal simply displaying duplicate data.

Observations

1. The normal configuration file results in Group 0 parse fail and Boot2 fail.
2. The auto configuration plus efusedata.bin produces a valid signed image.
3. Hash verification and signature verification both pass.
4. The application reaches board init done.
5. The partition table and firmware information are printed correctly.
6. The reset occurs later, during or immediately after RF parameter initialization.
7. The reset happens even when the host MCU SPI communication is not running.
8. The reboot occurs very quickly, approximately every 0.4 to 0.6 seconds.
9. The application counter increases between boots.
10. I do not see an explicit watchdog, exception, or hard-fault message before the restart.

Questions

Could someone please help clarify the following?

1. Is the reset during rfparam initialization caused by:

   • an internal watchdog,
   • invalid or missing RF calibration data,
   • incorrect eFuse contents,
   • a power supply issue,
   • an incompatible firmware package,
   • or a hardware reset signal?

2. What exactly does Counter value=254/255 represent? Is this a boot counter, watchdog counter, or another persistent value?

3. Is the message below expected for this module?

flash_info NO

psram_info NO

1. Is lp_fw not found normal for the SPI NCP firmware, or should an additional low-power firmware image be flashed?

2. Should efusedata.bin be programmed for every module, or is it intended only for specific development or manufacturing conditions?

3. Which signals should I monitor to determine the reset source?

   • CHIP_EN
   • BOOT
   • 3.3 V supply
   • reset pin
   • UART TX
   • 32 kHz output

4. Is there any command or Boot2 diagnostic option that can display the reset reason or watchdog status?

5. Could you please provide the correct complete flashing command and firmware file set for:

   • ST67W611M1
   • T01 architecture
   • SPI NCP firmware version 2.0.106.

Thank you.

 

[EPASZ.1]

I think there is confusion about the CS pin states. As you say “the host should keep CS inactive until the module requests an SPI transfer through SPI_RDY” - this is correct. But “SPI_CS is driven by the host MCU and remains High after reset” is incorrect - on ST67W611M1, the CS is active high - as explained in the previously linked wiki article. Try to correct this on your side.

For flashing: efuse.bin needs to be included every time.

32 kHz clock: as I mentioned above, these pins are an input to the ST67W611M1 (not an output) - if there is no signal provided by the host, it does not make much sense to measure anything on them. And no, providing the LSE clock is not strictly needed for the module to run.

Similar cyclic-reset scenarios were observed before in cases where the power supply was dropping too much during module radio initialization. There is a power consumption peak. If the CS modification does not help, you can try to monitor the 3V3 line and make sure it does not drop below 2.97V.