ST67W611M1 (X-NUCLEO-67W61M1) on NUCLEO-H753ZI: SPI magic mismatch 0x5501, unclear if firmware flashed, QConn_Flash lock question

[G Estheru Rani]

Hi,

I'm integrating a newly ordered X-NUCLEO-67W61M1 shield with a NUCLEO-H753ZI board, using the X-CUBE-ST67W61 package. I'm hitting an init failure and want to confirm the root cause before I flash anything, since I have some open questions about the flashing process itself.

1. Original symptom — SPI header validation failure at boot

Running the ST67W6X CLI/Echo application, I consistently get:

EXTI callback
Invalid magic 0x5501
Invalid spi header from peer, magic 0x5501, len (0, 0x0), version 0, type 0 flags 0x0, rsvd 0x1
sem_if_ready not received
sem_if_ready not received
Could not init Modem handler
[ERROR] in W6X_Init API
W61 Init failed
Failed to initialize ST67W6X Driver, 2

This happens on every boot, identically, every time — not intermittent. Expected magic is 0x55AA; I consistently receive 0x5501 (high byte correct, low byte wrong).

2. What I've verified so far

To isolate whether this is a wiring issue or a missing-firmware issue, I connected a USB-to-UART (Silicon Labs CP210x) adapter directly to the module's UART pins in standalone mode (BOOT→VDDIO, CHIP_EN→3.3V, bypassing the H753ZI/SPI entirely), and ran the read-only diagnostic tool:

NCP_info\QConn_Eflash.exe -r --efuse --chipname=qcc743 -p COM5 --start=0x0 --end=0x1ff --file=flash.bin

Result:

• ROM bootloader handshake succeeds
• Valid chip ID returned: 005257323753600101
• eFuse read fails: ErrorCode: 0020, ErrorMsg: QCC74X EFUSE READ FAIL, followed by ErrorCode: 0005, ErrorMsg: QCC74X BURN RETRY FAIL
• No flash.bin output file was produced as a result

3. My questions

Q1. Does the pattern above (ROM bootloader responds + valid chip ID, but eFuse read fails) indicate that mission-mode firmware has never been flashed onto this module? Or is eFuse read failure unrelated to whether mission firmware (e.g. st67w611m_mission_t01) is present?

Q2. Is there a reliable, preferably non-destructive way to check whether mission firmware is already present on the module, before committing to a flash?

Q3. Since NUCLEO-H753ZI isn't in the pre-built board list for NCP_update_mission_profile_t01.bat (only NUCLEO-U575ZI-Q, NUCLEO-H7S3L8, NUCLEO-H563ZI, NUCLEO-N657X0-Q are supported), I've been planning to run QConn_Flash_Cmd.exe directly in standalone mode via my CP210x adapter, using:

QConn_Flash\QConn_Flash_Cmd.exe --port COM5 --config NCP_Binaries\mission_t01_flash_prog_cfg.ini --efuse=NCP_Binaries\efusedata.bin

Is this a valid/supported approach for a board not in the pre-built list?

Q4. This command prints the following warning:

"You are about to load a signed binary to the NCP."
"This will lock the ST67W61M if not yet locked."

Could you clarify exactly what this lock does? Specifically:

• Is this an eFuse-based, permanent/one-time lock, or is it reversible?
• Does it restrict anything for normal development use with official ST-signed mission binaries (i.e., can the module still be reflashed with newer official mission binaries afterward)?
• Is this expected/normal for a brand-new, never-flashed module (i.e., should I expect to see this warning the very first time regardless)?

4. My setup

• Host: NUCLEO-H753ZI
• Shield: X-NUCLEO-67W61M1 (freshly purchased, never previously flashed as far as I know)
• Package: X-CUBE-ST67W61 (downloaded from st.com)
• Mission binary available locally: st67w611m_mission_t01_v2.0.106.bin (also have v2.0.89 and v2.0.97 available)
• boot2 binary available: st67w611m_boot2_v8.1.9.bin

Any guidance before I commit to the flash step would be appreciated — want to make sure I understand the lock behavior first since it sounds like it may not be reversible.

Thanks in advance!

[TarikAb]

Hi ​@G Estheru Rani ,

Q1/Q2

All ST67W611M1 modules are flashed at the fab with a mission binary. An “empty” module should not occur.

A magic word of 0x5501 indicates that the module contains the earliest released binary, which is not compatible with recent X-CUBE-ST67W61 versions. As recommended in the documentation, update the module binary to the version included in the X-CUBE-ST67W61 package in use. This recommendation also applies when the module contains a more recent binary that is compatible with X-CUBE.

The T01/T02 architectures were introduced in X-CUBE-ST67W61 V1.1.0. The binary in the module is older.

I ran the QConn_Eflash.exe tool on a similar module with the old binary, by using the X-NUCLEO and STM32U5 NUCLEO boards with the bootloader.bin file in the STM32, which sets the module to UART mode. The result was correct: successful handshake, successful eFuse read, and flash.bin created. It is not clear to me at which step the eFuse read failed, because the module entered UART mode successfully, as the successful handshake confirms.

Q3

Yes, this is a valid approach. If required, the provided .bat file can also be used by porting the NCP_Loader project to the selected microcontroller and generating the bootloader.bin file. Then update the .bat file to add the microcontroller to the originally supported ones.

Q4

All ST67W611M1 modules are permanently locked and can run only ST-signed binaries. This lock does not prevent an update of the module with a newer ST-signed binary.

However, the warning mentioned is displayed only when the .bat file is used, not when the QConn_Flash_Cmd.exe tool runs in standalone mode.

I suggest you update the binary to version 2.0.106.

Best regards,

Tarik