cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB 2.5mA static current after advertising stops (P2P server)

lizerd
Associate III

So this is my third day working on this problem.

I have created an P2P server project based after the example and the MOOC videos.

It works just fine, no problem during the first 60 seconds.

The current consumption is around 200uA during advertising.

But when the advertising stops the current goes up to 2.0 - 2.5mA

0693W00000GW62QQAT.png 

I have compared the p2p server project example file by file, and there is nothing that i can find that could cause this.

The board is custom designed by me, and all the IO ports are electrical disconnected to any other parts of the board. the oscillators and components are taken from a WB55 dev board from ST.

The MCU is the STM32WB35CEU7A with the latest FUS V1.2.0 and BLE_Stack_full V1.12.1

Project is based on cube V1.12.0

I have made two identical PCB boards, result is the same on both.

I have added a Task that blinks an led each 5 seconds, and additional led that shows when the M4 core is running. And both blinks the same time both before and after advertising stops.

So my thought is that the M0 core is stuck and not in sleep mode after the advertising stops.

I have included the project with code.

 

Is there a way to determent if the M0 core is in sleep mode or running/stuck ?

7 REPLIES 7
lizerd
Associate III

Here is the schematic.

0693W00000GW6pmQAD.png

lizerd
Associate III

if I change app_ble.c so it do not call aci_gap_set_non_discoverable();, then the consumption go down til 18uA during APP_BLE_LP_ADV

from

static void Adv_Cancel( void )
{
  if (BleApplicationContext.Device_Connection_Status != APP_BLE_CONNECTED_SERVER)
  {
    tBleStatus result = 0x00;
 
    result = aci_gap_set_non_discoverable();
 
    BleApplicationContext.Device_Connection_Status = APP_BLE_IDLE;
    if (result == BLE_STATUS_SUCCESS)
    {
      APP_DBG_MSG("  \r\n\r");APP_DBG_MSG("** STOP ADVERTISING **  \r\n\r");
    }
    else
    {
      APP_DBG_MSG("** STOP ADVERTISING **  Failed \r\n\r");
    }
  }

to

static void Adv_Cancel( void )
{
  if (BleApplicationContext.Device_Connection_Status != APP_BLE_CONNECTED_SERVER)
  {
	  Adv_Request(APP_BLE_LP_ADV);
  }
}

but as soon I call the aci_gap_set_non_discoverable(); the MCU current goes up to 2.0mA

lizerd
Associate III

So I I made a new project and used custom BLE temple instead of P2Ptemplet.

Got everything working, BLE and RTC wakeup and so on, can connect to device by BLE. Consumption is down to 40uA with slower advertising.

I have an task that is triggered every 5 seconds

#define PERIOD_WAKEUP_TIME			(5.0*1000*1000/CFG_TS_TICK_VAL)		//1.0sec, 1Hz
uint8_t								Periodic_Wakeup_timer_Id;
void Periodic_Wakeup_Callback(void);
 
 
 
void MX_APPE_Config( void )
{
...........
 
  HW_TS_Create(CFG_TIM_PROC_ID_ISR, &Periodic_Wakeup_timer_Id, hw_ts_Repeated, Periodic_Wakeup_Callback);
  HW_TS_Start(Periodic_Wakeup_timer_Id, PERIOD_WAKEUP_TIME); // <--start with this
 
   return;
}

and the callback

void Periodic_Wakeup_Callback(void)
{
	GPIO_InitTypeDef GPIO_InitStruct = {0};
 
 
	__HAL_RCC_GPIOB_CLK_ENABLE();
	__HAL_RCC_GPIOH_CLK_ENABLE();
 
	GPIO_InitStruct.Pin = LED_BLUE_Pin|LED_GREEN_Pin;
	GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
	GPIO_InitStruct.Pin = LED_RED_Pin;
	GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
	HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);
 
 
 
 
 
	  if(__HAL_PWR_GET_FLAG(PWR_FLAG_C2SB) != RESET)
	  {
		  HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_SET);
	  }
	  else if(__HAL_PWR_GET_FLAG(PWR_FLAG_C2STOP) != RESET)
	  {
		  HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_SET);
	  }
	  else if(__HAL_PWR_GET_FLAG(PWR_FLAG_C2DEEPSLEEP) != RESET)
	  {
		  HAL_GPIO_WritePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin, GPIO_PIN_SET);
	  }
	  else
	  {
		  HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_SET);
		  HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_SET);
		  HAL_GPIO_WritePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin, GPIO_PIN_SET);
	  }
 
 
		HAL_Delay(10);
		HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_RESET);
		HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_RESET);
		HAL_GPIO_WritePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin, GPIO_PIN_RESET);
}

And I trigger the Adv_Cancel() by this task, Its triggered by a button with NIVC prio 14

UTIL_SEQ_SetTask(1 << CFG_TASK_ADV_CANCEL_ID, CFG_SCH_PRIO_0);

When the BLE is working only the red led blinks and the BLE can be seen and is connectable.

This means that the Core2 is PWR_FLAG_C2STOP -> Core2 is in stop mode.

but when I trigger the Adv_Cancel. All LEDS are blinking -> means that Core2 is running!!

And the consumption is 2mA

What can I do to make sure core 2 is in stop mode ??

The BLE is not visible anymore after Adv_Cancel() is called.

EIvan.2
Associate II

I have the exact same problem. After calling aci_gap_set_non_discoverable() the advertising stops, but the chip starts consuming 2 mA.

I don't understand what's wrong? I use STM32WB30 and stm32wb3x_BLE_Stack_full_fw.bin V1.12.0

Remi QUINTIN
ST Employee

This is a known issue resulting from the Flash protection mechanism.

This issue is corrected in the next WB FW version v1.13 that should be available on st site very soon.

Scott Löhr
Senior II

I had reported this as well here:

https://community.st.com/s/question/0D53W000016OzwjSAC/stm32wb-v112x-stop2-behavior-by-cpu2-after-advertising-how-to-work-around-or-resolve

@lizerd​, out of curiosity, I can find the above post from the "STM32 Wireless" landing page just by searching for "advertising v1.12 current", did you not search before asking or did it look like I had a different issue? 

Anyway, in the meanwhile, I have just reverted to v1.11 until ST releases v1.13.

Scott Löhr
Senior II

FYI: it looks like this issue is indeed fixed in v1.13.0 (but at a cost of 3 more flash pages for the CPU2 code).