Cómo depurar la fuga de corriente STM32L433

Tengo una placa de circuito con STM32L433 que tiene alrededor de 320 uA de consumo de corriente de referencia en el modo STOP 2. Solo LSE con un cristal de 32kHz está activo.

La placa tiene alimentación Vdda analógica separada que está deshabilitada para el modo de parada. (atado a tierra). Antes de deshabilitar Vdda, ADC, DAC y OPAMP se deshabilitan y sus pines se colocan en modo OD bajo.

La configuración se realizó mediante el software STM32CubeMX.

¿Alguna idea de cómo depurar esto? Desconecté y medí casi todos los periféricos externos para ver qué consume corriente, pero parece que el STM32L433 es el culpable.

Estoy midiendo la corriente con un osciloscopio usando una resistencia de 2 ohmios en serie con la batería. El LDO podría ser responsable de 20 uA, lo que aún deja 300 uA sin contabilizar.

EDITAR:

~ 120uA de él estaba usando STOP 0 en lugar de STOP 2. Esto fue un remanente de algunos experimentos. Ahora estoy en 200uA. También desconecté los chips BMI160 y DRV2603. Y ellos no son el problema.

EDIT2

He soldado otra placa con solo un STM32L433 y un LDO LP5907-3.0 y un par de condensadores de desacoplamiento. EL MISMO PROBLEMA.

Este es el código mínimo que usé para configurar los GPIO

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

El pin USB DM flota cuando la entrada USB está en modo de bajo consumo. Esto causó el drow actual de 200uA visto. Al tirar de este pin hacia abajo, se eliminan los 200 uA. Ahora estoy tratando de encontrar una forma de evitar esto en el firmware.

¿Tienes un esquema?
¿"Casi" todos los periféricos externos? ¿Por qué no es posible que sea uno de los que no desconectaste? ¿Por qué no estás usando un amperímetro para medir la corriente consumida?
@BenceKaulics lamentablemente no puedo compartirlo
@DiBosco los restantes son un acelerómetro BMI160 en modo de suspensión y un controlador de motor drv2603 deshabilitado. Estoy usando un osciloscopio porque el sistema se activa cada 10 ms, lo que es un pico en el consumo de corriente, aunque me interesa bajar la línea de base en el modo de parada.
@BenceKaulics Actualicé la pregunta con un tablero y un código mínimos. ¿Alguna idea ahora?
Tal vez podría configurar esos GPIO como HighZ antes de dormir (como entradas analógicas) en lugar de salidas push-pull.
Intenté eso. ANALOG o OUTPUT_PP, exactamente lo mismo. ¿Hay algo más que esté activado de forma predeterminada y deba desactivarse? No hice ninguna inicialización, excepto startup_stm32l433xx.s y el código en mi pregunta.
Es el pin USB DM flotando cuando el USB tiene poca potencia. Traté de reconfigurar el pin a analógico cuando estaba en modo de bajo consumo, pero parece que no es posible cuando el USB está configurado.
@pkuhar, ¿puede desconfigurar el USB y solo restaurarlo tras la detección de VBus? Dicho esto, este podría ser un momento para ver si puede ponerse en contacto con un ingeniero de aplicaciones ST y obtener su opinión sobre cómo se supone que debe hacer esto en el pensamiento de los diseñadores. O si solo quiere ser crudo, puede encontrar un valor de resistencia desplegable lo suficientemente grande como para no ser un problema en funcionamiento, pero lo suficientemente pequeño como para funcionar como un guardián para desviar la región problemática. 100K? 1M?
Gracias cris. Voy con una ruta separada de detección de VBUS.
Buena investigación. Debe ponerlo en una respuesta adecuada en lugar de editar la pregunta.
Estoy esperando encontrar la solución final antes de la respuesta. gracias por los consejos

Respuestas (2)

Después de pasar demasiado tiempo en esto aquí están los resultados.

Cuando el USB se pone en un modo de bajo consumo después de suspender con

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

Hay un residuo restante ~200uA causado por un pin USB DM flotante. (Las entradas digitales flotantes consumen energía ( Implicaciones de las entradas CMOS lentas o flotantes )

La solución es usar/habilitar el circuito de detección de carga de la batería que está integrado en estos chips.

Algo como esto:

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;
}

Nota: HAL tiene una void HAL_PCDEx_BCD_VBUSDetect(PCD_HandleTypeDef *hpcd) función, pero se espera que la llame usted mismo después de que se detecte la alimentación de VBus. Lo que significa que se usó un pin adicional y, en mi caso, una gran reorganización del diseño. Algunos detalles sobre el circuito recomendado del ST se encuentran aquí. Guías de PCB y hardware USB usando MCU STM32

Todavía hay unos 40uA causados ​​por el LDO (~10uA) y una corriente de fuga inversa de un diodo Schottky (~30uA), pero eso al menos está documentado.

Es probable que tengas algún pin de entrada flotando. Esto hará que fluya una corriente "excesiva" en la etapa de entrada. Configure todos los pines como salida y jálelos para guardar niveles cuando vaya a dormir o asegúrese de que todos los pines de entrada estén en los niveles de voltaje adecuados. Tenga en cuenta que los pines de entrada tienen algo de corriente de fuga. Es decir, la resistencia pull-up/down tiene que ser lo suficientemente pequeña para seguir tirando a un nivel válido.

Ya mencioné esto en la pregunta.
Cómo depurar la fuga de corriente STM32L433
RespuestasAquíPolítica de privacidad1y, 0v