Abnormal Execution Times During Low Power Mode and Bluetooth Communication

[mackgim]

Describe the set-up STM32WB55CG (Custom board) STM32Cube_FW_WB_V1.18.0 (stm32wb5x_BLE_Stack_light_fw.bin, stm32wb5x_FUS_fw.bin)

Describe the bug

Using an LPTIM with a 500Hz interrupt for transaction processing on an STM32WB55CG custom board has led to unexpected delays in execution times, particularly when waking from stop mode and during Bluetooth communication tasks.

1、Waking up from stop mode: Occasionally, executing the line while (LL_HSEM_1StepLock(HSEM, CFG_HW_RCC_SEMID)) (Within the 'ExitLowPower' function) after waking up from stop mode does not complete instantly. Instead, there can be a delay approximately equal to the Bluetooth connection interval, such as nearly 50ms for a 50ms connection interval. This issue does not occur with every execution of the while loop but tends to manifest roughly every 4 to 5 minutes. In one extreme case, the delay was observed after 45 minutes.

2、Updating GATT characteristic values: The function aci_gatt_update_char_value also experiences similar abnormal execution times. Specifically, during the execution of hci_send_req, the process may stall at hci_cmd_resp_wait(HCI_TL_DEFAULT_TIMEOUT); for a duration equivalent to a Bluetooth connection interval. Upon further observation, this delay occurs after SendCmd(opcode, p_cmd->clen, p_cmd->cparam), waiting for a Bluetooth cycle before the interrupt IPCC_C1_RX_IRQHandler arrives. This problem appears more frequently than the first, approximately once every 2 to 3 minutes.

It's important to note that these issues only arise when entering low power mode. Tests show that avoiding low power mode prevents these problems from occurring. Furthermore, if the device has previously entered low power mode, the second issue may still occur even if low power mode is no longer being used.

For reference, here are the implementations of hci_cmd_resp_release and hci_cmd_resp_wait:

void hci_cmd_resp_release(uint32_t Flag) { UTIL_SEQ_SetEvt(1 << CFG_IDLEEVT_HCI_CMD_EVT_RSP_ID); }

void hci_cmd_resp_wait(uint32_t Timeout) { UTIL_SEQ_WaitEvt(1 << CFG_IDLEEVT_HCI_CMD_EVT_RSP_ID); }

[RJMSTM]

ST Internal Reference: 175695

[RJMSTM]

Hello @mackgim,

The scenario is not very clear. To be able to analyze the issue, we need a concrete scenario which explain how to reproduce the issue or at least in which condition the issue is observed. The issue reported seems to be very strange and I think there is something application which is going wrong.

Regards, Rania

[ALABSTM]

See also #89