# How to debug STM32L433 Current leakage

I have a circuit board with STM32L433 that has around 320uA of baseline current draw in STOP 2 mode. Only LSE with a 32kHz crystal is active.

The board has separate analog Vdda power which is disabled for the stop mode. (tied to ground). Before disabling Vdda, ADC, DAC and OPAMP are disabled and their pins put into an OD low mode.

The configuration was done using the STM32CubeMX software.

Any ideas how to debug this? I disconnected and measured pretty much every external peripheral to see what is drawing current, but it seems like the STM32L433 is the culprit.

I'm measuring current with an oscilloscope using a 2ohm resistor in series with the battery. The LDO could be responsible for 20uA of it, which still leaves 300uA unaccounted for.

EDIT:

~ 120uA of it was using STOP 0 instead of STOP 2. This was left over from some experimentation. Now I'm at 200uA. I've also disconnected both the BMI160 and DRV2603 chips. And they aren't the problem.

EDIT2

I've soldered another board with just an STM32L433 and an LDO LP5907-3.0 and a couple of decoupling capacitors. SAME PROBLEM.

This is the minimal code I used to set the GPIOs

GPIO_InitTypeDef GPIO_InitStruct;

/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOC_CLK_ENABLE()
;
__HAL_RCC_GPIOH_CLK_ENABLE()
;
__HAL_RCC_GPIOA_CLK_ENABLE()
;
__HAL_RCC_GPIOB_CLK_ENABLE()
;

GPIO_InitStruct.Pin = 0xFFFFFFFF;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOA, GPIO_InitStruct.Pin, GPIO_PIN_SET);

GPIO_InitStruct.Pin = 0xFFFFFFFF;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOB, GPIO_InitStruct.Pin, GPIO_PIN_SET);

GPIO_InitStruct.Pin = 0xFFFFFFFF;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOC, GPIO_InitStruct.Pin, GPIO_PIN_SET);

GPIO_InitStruct.Pin = 0xFFFFFFFF;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOH, GPIO_InitStruct.Pin, GPIO_PIN_SET);

//BOOT0 PIN
GPIO_InitStruct.Pin = GPIO_PIN_3;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);

HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);


EDIT3

USB DM pin floats when USB in is low power mode. This caused the seen 200uA current drow. Pulling this pin down externally removes the 200uA. Now i'm trying to find a way around this in firmware.

• Do you have a schematic? – Bence Kaulics Sep 20 '17 at 10:02
• "Pretty much" every external peripheral? Why is not possible it's one of the ones you didn't disconnect? Why are you not using an ammeter to measure current drawn? – DiBosco Sep 20 '17 at 12:50
• @BenceKaulics unfortunatly i can’t share it – pkuhar Sep 20 '17 at 15:41
• @DiBosco the remaing ones Are a BMI160 accelerometer in suspend mode and disabled drv2603 motor driver. I’m using an oscilloscope because the system wakes up every 10ms which is a spike in current consumption, I’m interesting lowering the baseline in the stop mode though – pkuhar Sep 20 '17 at 15:42
• Nice investigation. You should put it into a proper answer instead of an edit to the question. – Bence Kaulics Sep 22 '17 at 21:18

After spending much too much time on this here are the results.

When USB is put to a low power mode after suspend with

void HAL_PCD_IRQHandler(PCD_HandleTypeDef *hpcd){
.....
hpcd->Instance->CNTR |= USB_CNTR_FSUSP;
hpcd->Instance->CNTR |= USB_CNTR_LPMODE;
...


There is a remaining residual ~200uA caused by a floating USB DM pin.(Floating digital inputs draw power (Implications of Slow or Floating CMOS Inputs)

The solution is to use/enable the Battery Charge Detection circuit that's built into this chips.

Something like this:

PCD_HandleTypeDef *hpcd = (PCD_HandleTypeDef*)hUsbDeviceFS.pData;
USB_TypeDef *USBx = hpcd->Instance;

int stabilizationCounter = 0;

HAL_PCDEx_ActivateBCD(hpcd);

//run on a 10ms Timer
if( USBx->BCDR & USB_BCDR_DCDET ){
stabilizationCounter++;
if( stabilizationCounter >= USBPC_STABILIZATION_TIME ){
USBD_Start(&hUsbDeviceFS);
//stop the timer
}
}else{
stabilizationCounter = 0;
}


Note: HAL does have a void HAL_PCDEx_BCD_VBUSDetect(PCD_HandleTypeDef *hpcd)  function, but your are expected to call this yourself after VBus power is detected. Which means an extra pin used and in my case a big layout reshuffle. Some details on the ST's recommended circuit is here USB hardware and PCB guidelines using STM32 MCUs

Is still have some 40uA caused by the LDO (~10uA) and a reverse leakage current of a Schottky diode (~30uA) but that's at least documented.

It is likely that you have some input pin floating. This will cause "excessive" current flowing in the input stage. Either configure all pins as output and pull them to save levels when you go to sleep or make sure that all input pins are at proper voltage levels. Be aware that the input pins have some leakage current. I.e. the pull-up/down resistor has to be small enough to still pull to a valid level.

• I mentioned this in the question already. – pkuhar Sep 22 '17 at 20:28