X-CUBE-ST67W61 V1.2.0 — sem_if_ready not received on NUCLEO-N657X0-Q

Question

(official project, W61 firmware updated, full setup completed)

**[BUG/HELP] X-CUBE-ST67W61 V1.2.0 — sem_if_ready not received on NUCLEO-N657X0-Q after complete setup**

---

**Hardware:**
- NUCLEO-N657X0-Q (MB1940)
- X-NUCLEO-67W61M1 (MB2230)
- JP1 and JP2 closed, Arduino connectors fully seated

**Software:**
- STM32CubeIDE 1.16.x
- X-CUBE-ST67W61 V1.2.0
- X-CUBE-FREERTOS V1.4.0
- STM32CubeProgrammer v2.22.0
- Project: ST67W6X_Echo for NUCLEO-N657X0-Q (official, unmodified)

---

**Setup completed (all steps verified):**

1. W61 firmware updated to st67w611m_mission_t01_v2.0.97 using QConn_Flash_Cmd via COM port — [All Success] with SHA256 match
2. FSBL compiled from official project (0 errors, 0 warnings), signed with STM32_SigningTool_CLI --align (v2.22.0), flashed to 0x70000000 and verified successfully
3. OTP word 124 programmed to 0x00018000 (HSLV_VDDIO2 + HSLV_VDDIO3)
4. Boot switches in flash boot mode (BOOT0: 1-2, BOOT1: 1-2)
5. eraTerm on STLink VCP, 921600 baud

---

**Terminal output (always the same):**

```
#### Welcome to ST67W6X Wi-Fi Echo Application #####
# build: [timestamp]
--------------- Host info ---------------
Host FW Version: 1.2.0
[ERROR] [4000] [ST67W6XTask] (w61_at_sys.c:340) sem_if_ready not received
[ERROR] [4000] [ST67W6XTask] (w61_at_common.c:375) sem_if_ready not received
[ERROR] [4000] [ST67W6XTask] (w61_at_sys.c:312) Could not init Modem handler
[ERROR] [4000] [ST67W6XTask] (main_app.c:554) [ERROR] in W6X_Init API
[ERROR] [4000] [ST67W6XTask] (w6x_sys.c:115) W61 Init failed
[ERROR] [4000] [ST67W6XTask] (main_app.c:240) Failed to initialize ST67W6X Driver, 2
##### Application end
```

**Note:** Before updating W61 firmware, the error was "Invalid magic 0x5501", confirming the firmware update was successful. The current error is different and persists regardless of power cycling.

**Pin configuration from main.h (N657 project):**
- SPI5 (hspi5)
- SPI_RDY: PE9
- CHIP_EN: PE10
- SPI_CS: PA3
- SPI_CLK: PE15
- SPI_MISO: PG1
- SPI_MOSI: PG2
- BOOT: PD5

**Questions:**
1. Is there a known issue with SPI5 DMA initialization on STM32N6 that could prevent SPI_RDY from being detected?
2. Are there any additional hardware or software steps specific to NUCLEO-N657X0-Q that are not documented in the README?
3. Is OTP word 124 (0x00018000) the correct configuration for this board, or does the N657 require a different HSLV setting for SPI5?

---

**Feedback for ST (constructive):**

I want to raise a concern that goes beyond this specific bug. The NUCLEO-N657X0-Q + X-NUCLEO-67W61M1 combination is marketed as a supported, out-of-the-box evaluation platform. However, the actual experience required:

- Manual binary signing with CLI tools
- OTP programming (irreversible) not mentioned in the Echo README
- External Loader configuration undocumented for the N6
- No equivalent of the NCP_update_mission_profile_t01.bat script for the N657 (only NUCLEO-U575ZI-Q is supported by the script)
- No step-by-step getting started guide specific to the N657 host

The NUCLEO-U575ZI-Q has a working .bat script that automates the entire setup in minutes. The N657 has none. For educators and students trying to evaluate Wi-Fi connectivity on what is supposedly a "supported" board, this gap represents a significant barrier.

This is not a complaint — it is a request: please provide a getting started guide for NUCLEO-N657X0-Q equivalent to what exists for NUCLEO-U575ZI-Q. The hardware combination works (partially), but the documentation gap makes it inaccessible to most users.

Thank you for your support.

Louis AUDOLY · Accepted Answer

Hello @Kirchof ,Thank you for your post.Indeed, the OTP programming wasn't clearly described in the readme; you can find a post on the community describing the process to successfully program OTPs on the NUCLEO-N657. But yes, OTP word 124 (0x00018000) the correct configuration for this board.This shall be done before executing the .bat script.The NUCLEO-N657X0-Q is supported by the NCP_update_mission_profile_t01.bat script, as well as NUCLEO-H7S3L8, NUCLEO-H563ZI and NUCLEO-U575ZI-Q. You will need to perform manual operation during the process that are explain during the script execution.Once this done, could you please try to execute NCP_get_chip_info.bat script to check if the ST67W61 has been correctly flashed (can you provide the output of this script if you encounter any issue).You could also plug an FTDI on the X-NUCLEO-67W61M1, connect with baud rate of 2000000, and verify the ST67 is alive and responsive.If so, please check once again with Echo project if you face the same issues you described in your postFYI, there is a new version of the X-CUBE-ST67W61, v1.3.0, you can find here.Let me know if you have any issue or if this solves it.RegardsLouis

Kirchof · Answer

Hello Louis,Thank you very much for your quick response; it was extremely helpful.Following your guidance, I was able to resolve the issue completely. Here is a summary of what worked:1. I ran the NCP_update_mission_profile_t01.bat script, which correctly detected the NUCLEO-N657X0-Q board and guided me through the manual steps (switch changes, resets, press any key). The script completed successfully.2. I ran NCP_get_chip_info.bat to verify the ST67W611M — it returned [All Success] with the correct chip ID, MAC address, and SDK Version 2.0.97.3. I recompiled the ST67W6X_Echo project for NUCLEO-N657X0-Q (0 errors, 0 warnings), signed the binary with STM32_SigningTool_CLI --align, and flashed it to 0x70000000.4. With boot switches in flash mode (BOOT0: 1-2, BOOT1: 1-2), the application started correctly in TeraTerm at 921600 baud. The sem_if_ready error is gone.5. The CLI application successfully scanned nearby Wi-Fi networks, connected to our access point, obtained an IP address via DHCP, and responded to ping commands.The key missing step that was not documented in the README was the OTP word 124 programming (value 0x00018000 for HSLV_VDDIO2 + HSLV_VDDIO3). Without this, the SPI communication with the W61 never initializes, regardless of firmware version. I found a reference to this in the community but it was not linked from the Echo project README.Regarding V1.3.0 — thank you for the heads up. We will evaluate it for our next iteration.As a final note, and I hope this is taken constructively: this combination (NUCLEO-N657X0-Q + X-NUCLEO-67W61M1) is officially supported and marketed as an evaluation platform, but the getting started experience required significant undocumented steps — OTP programming, manual binary signing, External Loader configuration, and no equivalent of the automated .bat script that exists for NUCLEO-U575ZI-Q. For educators and students in embedded systems courses, this gap can feel like quite a hurdle. As a dedicated professor passionate about connecting with my students and exploring new technology, I believe that having a clear and comprehensive getting started guide for NUCLEO-N657X0-Q—similar to what is available for NUCLEO-U575ZI-Q—would be a wonderful and helpful addition to the documentation. It would make a big difference in making the material more accessible and welcoming for everyone involved.Thank you again for your support.Best regards

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded