2025-12-17 5:10 AM
Greetings,
I'm trying to run an application using X-CUBE-ST67W61, but I'm encountering a problem at this line in w61_at_common.c:
int32_t W61_AT_ModemInit(W61_Object_t *Obj)
{
(...)
xReturned = xSemaphoreTake(mdm->sem_if_ready, pdMS_TO_TICKS(4000));
(...)
}everytime, xReturned equals 0, which means that sem_if_ready is not received.
My setup consists of STM32N6570-DK with X-NUCLEO-67W61M1, and the code I'm trying to run is mostly ble_p2p_server app from X-CUBE-ST67W61.
Some of the SPI communication starts, as seen below:
but these are the only signals that are appearing.
Solved! Go to Solution.
2026-01-09 7:29 AM
Up to now, the ST67 boards were shipping with an old FW flashed corresponding to package 1.0.0 - they need to be updated. In fact, there was a known issue with the initialization phase in this version which had the same symptoms as what you are seeing.
With the 1.2.0 recently released, the FW shipped on the boards should soon change. But yes, you should update it in some way.
2026-01-06 12:07 AM
The fact that sem_if_ready is not received means the first message coming from the NCP is not "\r\nready\r\n" as it should be. Which is also true based on the SPI trace you shared - the first three characters are correct (in the second frame) but the rest seem to be incorrect.
Aside from making sure the HW connection is good, there are a few points to check.
2026-01-08 4:17 AM - edited 2026-01-08 4:56 AM
Hello,
I have exactly the same problem as Shirovaty mentioned. I'm using the STM32H735G-DK board with the X-NUCLEO-67W61M1 board.
On my end, I started a project with the initialized peripherals of the STM32H735G-DK board, removed everything unnecessary, and adapted it for the X-NUCLEO-67W61M1 board.
I'm using X-CUBE-ST67W61 v1.1.0 (v1.2.0 isn't yet available for STM32CubeMX...). I compared the problematic code in w61_at_common.c from v1.1.0 and v1.2.0, and the code is different. Could this mean there was a bug in v1.1.0?
Thanks.
Edit: I tried X-CUBE-ST67W61 v1.2.0 by copying the files, and I have the same issue. Analyzing the code, I see that the problematic line mentioned in the first post is simply moved into a function.
2026-01-08 11:47 PM
As you say, there aren't really breaking changes in this part of the 1.2.0 version. It is just always preferable to have the latest version - and at least to know which version you are using.
The two points from my previous post still stand: Have you updated the NCP FW (https://wiki.st.com/stm32mcu/wiki/Connectivity:Wi-Fi_MCU_Hardware_Setup#How_to_run_mission_mode)? And I cannot judge to correctness of the pin and peripheral settings. It needs to be correct to prevent errors - see How to use X-CUBE-ST67W61 STM32CubeMX pack - stm32mcu.
On my side, I don't see such an issue, so I cannot judge anymore from the provided details.
2026-01-09 5:09 AM
I don't know the NCP FW version because I don't have any UART to RS232 converter (I ordered one) and I don't have a compatible board (I ordered NUCLEO-H7S3L8).
I followed the steps of the "How to use X-CUBE-ST67W61 STM32CubeMX pack", but according to my STM32H735G-DK board (SPI5 with DMA1 Stream 1/2 , USART1, GPIOs, etc.) and I selected BLE_p2Server.
The ST67 architecture is not specified in the steps. I selected the T01 architecture. What is the default NCP FW? If the NCP FW architecture differs from what is selected, could that explain the cause of the problem?
Thanks.
2026-01-09 7:29 AM
Up to now, the ST67 boards were shipping with an old FW flashed corresponding to package 1.0.0 - they need to be updated. In fact, there was a known issue with the initialization phase in this version which had the same symptoms as what you are seeing.
With the 1.2.0 recently released, the FW shipped on the boards should soon change. But yes, you should update it in some way.
2026-01-12 1:13 PM
I updated my ST67 board to 1.2.0 using the NCP_update_mission_profile_t01.bat script and the NUCLEO-H7S3L8.
I tried again with my STM32H735G-DK board and the BLE initialization was completed. My ST67 board is now discoverable by my computer.
For me, updating the ST67 board was the solution. I can now continue my review of the board.
Thank you @EPASZ.1 !