cancel
Showing results for 
Search instead for 
Did you mean: 

ST67W611M1 / X-CUBE-ST67W61: RTOS "semaphore sem not ready" error when attempting 0.2µA hardware shutdown via CHIP_EN during runtime

MSalm.2
Associate

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!



0 REPLIES 0