ST67W611M1: RTOS "semaphore sem not ready" error when attempting Shutdown state

[MSalm.2]

Hello everyone,

I am working with the ST67W611M1 Wi-Fi/BLE combo module alongside the X-CUBE-ST67W61 middleware running on an RTOS.

My goal is to put the module into its absolute lowest power state. According to the datasheet, the Shutdown state consumes 0.2 µA, but achieving this requires a complete power-down via the hardware CHIP_EN pin , rather than just using the software DeepSleep AT commands (AT+PWR=2 which consumes 90 µA).

When our device first boots up, the initialization works perfectly. However, in real-time operation, when I try to manually de-initialize the module to kill the power and then re-initialize it later, it gives me a semaphore sem not ready error.

Here is the sequence that reproduces the issue:

W6X_App_Cb_t cb = { 0 };
cb.APP_error_cb = error_cb;
cb.APP_ble_cb   = internal_ble_cb;
W6X_RegisterAppCb(&cb);

// First boot - This works perfectly
W6X_Status_t ret = W6X_Init(); 

/* ... System runs normally in real-time ... */

// Later, attempting to tear down the software/hardware for 0.2uA shutdown
W6X_DeInit(); 

osDelay(200);

// Trying to wake the module back up from cold boot
ret = W6X_Init(); // <--- Fails here in real-time: "semaphore sem not ready"

It appears that W6X_DeInit() pulls the CHIP_EN pin low to kill the hardware, but it might be doing so while the background SPI Rx thread is still blocked waiting on the SPI_RDY semaphore. Because the hardware drops off, the semaphore is never released, causing the subsequent W6X_Init() to fail when it tries to recreate or grab that stale RTOS object.

My questions for the community/ST staff:

1. What is the officially recommended, graceful teardown sequence to completely suspend the X-CUBE network/BLE stack before calling W6X_DeInit() in real-time operation?

2. Does W6X_DeInit() fully destroy all internal threads and semaphores it creates, or do I need to manually delete the SPI Rx semaphores to prevent this deadlock?

3. Is there an alternative high-level API approach to safely execute a full 0.2 µA hardware shutdown and cold-boot recovery without breaking the RTOS state?

Any guidance or workarounds would be greatly appreciated. Thank you!

[Louis AUDOLY]

Hello @MSalm.2 ,

Could you please provide more information about your setup (version of the X-CUBE-ST67 you're using) ?

Do you drive the CHIP_EN pin by your side or do you manage it thanks to the W6X_Init() / W6X_DeInit() functions ?
This must be done by the W6X functions otherwise this could lead to unexpected behavior, as you are facing with SPI.

Also, its required to de-init and re-init all the modules previously initialized to comeback in a clean and functional state after the toggle of the CHIP_EN pin.

This could be done as below:

  ret = W6X_Init();
  /* ... */

  /* Initialize the ST67W6X Wi-Fi module */
  ret = W6X_WiFi_Init();
  /* ... */

  /* Initialize the ST67W6X Network module */
  ret = W6X_Net_Init();
  /* ... */

  /* Initialize the ST67W6X MQTT module */
  ret = W6X_MQTT_Init(&mqtt_recv_data);
  /* ... */

  /* Initialize the ST67W6X BLE module */
  ret = W6X_Ble_Init(1, NULL, 0);
  /* ... */

  /* Process of the application */ 

  /* Process of the application */ 

  /* De-initialize the ST67W6X BLE module */
  W6X_Ble_DeInit();

  /* De-initialize the ST67W6X MQTT module */
  W6X_MQTT_DeInit();

  /* De-initialize the ST67W6X Network module */
  W6X_Net_DeInit();

  /* De-initialize the ST67W6X Wi-Fi module */
  W6X_WiFi_DeInit();

  /* De-initialize the ST67W6X Driver */
  W6X_DeInit();

  /* RE DO THE COMPLETE INIT SEQUENCE OF THE MODULES YOU NEED */

Please let us know if this solves your issue.

Regards

Louis

[MSalm.2]

Thanks for the feedback!

It's Cube MX (Software Components) Middleware Version "1.2.0".

Do you drive the CHIP_EN pin by your side or do you manage it thanks to the W6X_Init() / W6X_DeInit() functions ?
=>  CHIP_EN (is internally handled, at spi_port.c file, spi_port_init () function and  spi_port_deinit() function.

Yes! Exactly (I am exactly following the sequence you mentioned.)

I am wondering why it always works at first init, and then when I try to deinit and reinit, it does not work.
I don't exactly understand the middleware; I am only interacting at the spi_port.c layer.

Please let me know if you need any info. Thanks

[Louis AUDOLY]

Hello,

For your information there is a newer 1.3.0 version available.

Indeed, CHIP_EN is manage by those functions, but they should not be called directly.
The W6X_Init() / W6X_DeInit() functions only must be called and will manage on their own the init/deinit of the SPI, and so the boot of the ST67.

Otherwise,  if you manage the CHIP_EN directly through spi_port_deinit() function, this will work correctly because the ST67 will be shut down, but after calling spi_port_init(), the ST67 will boot and if we do not catch its ready sequence, we cannot ensure it booted correctly. That's why you got an issue in the W6X_Init().

Try removing the call to spi_port_init/deinit() function and to interact only with W6X APIs (following the exact sequence I gave without adding anything)

Let me know if this solves your issue

Regards

Louis