Configuración nRF52 GPIO en modo de suspensión para evitar que los periféricos consuman corriente

Tengo una placa alimentada por batería con un nRF52832 y algunos periféricos para los que estoy escribiendo un nuevo firmware. Cuando se configura para dormir (NRF_POWER->SYSTEMOFF=1;), la placa sigue consumiendo demasiada corriente (alrededor de 2 mA, el nRF está clasificado para <1 uA cuando está en suspensión). El pcb en sí está bien, con el firmware con el que vino, el consumo de energía en modo de suspensión fue muy bajo. Al principio pensé que podría ser un problema de software o de configuración, pero supongo que es probable que los periféricos consuman demasiada energía.

Cuando la placa se configura en modo de suspensión, la mayoría de los periféricos internos del SoC se apagan, pero se conserva la configuración GPIO. Probé el consumo de energía con un código mínimo (la primera declaración en main() es dormir), por lo que todos los GPIO se configuraron con la configuración predeterminada (entrada con interruptor interno desconectado).

¿Necesito establecer los GPIO en una determinada configuración para evitar que desperdicien energía?

  • Algunos periféricos están conectados a través de SPI o I2C. ¿Deberían los pines nRF usados ​​para SPI/I2C estar en una configuración específica cuando no se usa SPI/I2C, o está bien el valor predeterminado (entrada con interruptor interno desconectado)?
  • Un GPIO está impulsando un mosfet de canal n (con pulldown externo en la puerta) que impulsa un motor pequeño. Supongo que dado que hay un menú desplegable externo, ¿la configuración de pin predeterminada debería estar bien?
  • Algunos LED están conectados (GPIO -> Resistencia -> LED -> GND). Nuevamente, ¿supongo que el valor predeterminado debería estar bien?
  • El voltaje de la batería se mide a través de ADC en el divisor de voltaje.
  • Un interruptor activo-bajo tiene un pull-up externo.

¿Es crítico para alguno de estos periféricos configurar los GPIO de una manera específica para evitar la pérdida de energía?

Esquemas: https://mbientlab.com/community/uploads/editor/f6/3zbfr2s08vsb.pdf

(Estaba publicando esta pregunta en los foros nórdicos, pero noté que el problema es probablemente más general sobre la configuración de GPIO. Enlace al tema )

Editar: medí la corriente con un alcance. No pude llegar al pin del regulador de voltaje (pequeño) pero medí en serie con la batería (coloqué una resistencia de 10 ohmios en serie con la batería y medí con sondas a través de la resistencia). 10 mV equivale a 1 mA, por lo que el osciloscopio muestra alrededor de 2,2 mAingrese la descripción de la imagen aquí

Algunas ideas, supongo que está haciendo un ciclo de energía antes de medir la corriente, para que la sección de depuración del chip se apague. Una posibilidad es que el nRF se restablezca constantemente, ¿puede verificar la salida del regulador de 3V? Además, ¿por qué se derriba el SWCLK?
Sí, desconecté el depurador y volví a conectar la alimentación antes de medir la corriente. Supongo que SWCLK se retira porque el predecesor mcu (nRF51) tiene un problema de ruido en el puerto de depuración que podría solucionarse con dicho menú desplegable: devzone.nordicsemi.com/f/nordic-qa/16435/… . Tomaré algunas medidas en el regulador de 3V con un osciloscopio.
@EarthLord Medí la corriente con un alcance, agregué una captura de pantalla a mi primera publicación. Parece que el drenaje actual es bastante constante.
Asegúrese de que no se ejerzan E/S contra las resistencias de tracción (incluidas las internas ). Asegúrese de que ninguna E/S esté aplicando un voltaje lógico a ningún chip periférico externo cuando se haya apagado el suministro a esos chips. Y date cuenta de que tu divisor de voltaje va a consumir energía. Confirme su software en git y comience a sacar funcionalidad, es decir, nunca inicialice esto o aquello y vea cómo cambia la energía. También considere ejecutar su software en una placa de desarrollo o un módulo de placa de prueba sin ningún circuito externo...

Respuestas (1)

Resulta que esto era bastante simple:

No hay pullups externos en las líneas CS de los circuitos integrados conectados a SPI, por lo que estaban flotando. Ponerlos en salida alta resolvió el problema.