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 Network 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