STM32L1xx HAL_GPIO_Init Problema

Estoy desarrollando una aplicación para un proyecto universitario en mi placa STM32L1DISCO con el MCU STM32L152RC.

Configuré los pines y generé el código de inicio a través de STM32CubeMX. Estoy usando Atollic TrueSTUDIO como IDE.

El problema es que el código de inicio generado no puede ejecutarse en mi MCU. Después de dedicar mucho tiempo a la depuración, descubrí que el problema en el código es esta línea que usa la biblioteca HAL gpio:

HAL_GPIO_Init(IDD_CNT_EN_GPIO_Port, &GPIO_InitStruct);

Aunque el código anterior es correcto,

  GPIO_InitTypeDef GPIO_InitStruct;

  /* GPIO Ports Clock Enable */

 __HAL_RCC_GPIOC_CLK_ENABLE();

  __HAL_RCC_GPIOA_CLK_ENABLE();

__HAL_RCC_GPIOB_CLK_ENABLE();

  /*Configure GPIO pin Output Level */

HAL_GPIO_WritePin(IDD_CNT_EN_GPIO_Port, IDD_CNT_EN_Pin, GPIO_PIN_RESET);

  /*Configure GPIO pin : IDD_CNT_EN_Pin */

GPIO_InitStruct.Pin = IDD_CNT_EN_Pin;

GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

Después de revisar el código línea por línea durante la depuración, descubrí que la función HAL GPIO Init no se ejecuta y en su lugar da el error de tiempo de ejecución: "Target not Responding, reintenting...".

Cuando comento la línea HAL GPIO Init, el programa se ejecuta sin problemas.

STM32CubeMX incluye la biblioteca HAL en el código. Encima hay,

incluir "stm32l1xx_hal.h"

Entonces, no estoy seguro de qué está causando el problema que estoy viendo. Realmente agradecería su ayuda en esto ya que no sé qué intentar a continuación.

Gracias.

Debe ingresar al código de la función init y verificar más a fondo qué puede estar mal. Lo que también tuve una vez, pero que no estaba relacionado directamente con los pines GPIO, fue que en STM32CubeMx, en Sys, Debug no estaba configurado en Serial Wire. Esto provocó que de repente apareciera una depuración/pérdida de conexión durante la inicialización.
Hola Miguel, gracias por el comentario. Intenté su sugerencia y encontré que el culpable era este conjunto de código dentro de la función HAL_GPIO_Init: /* Configure el modo de dirección IO (Entrada, Salida, Alternativa o Analógica) */ temp = GPIOx->MODER; CLEAR_BIT(temp, GPIO_MODER_MODER0 << (posición * 2)); SET_BIT(temp, (GPIO_Init->Mode & GPIO_MODE) << (posición * 2)); GPIOx->MODER = temperatura; ¿Alguna idea de por qué estas líneas de código pueden ser problemáticas para la MCU?
No, lo siento, no me he sumergido tanto... ¿estás seguro de que usaste el tipo de placa/CPU correcto en CubeMx? También puede probar con otro pin GPIO (tal vez haya un conflicto en alguna parte).
¿Qué pin es ese IDD_CNT_EN_GPIO? PA13 o PA14 por casualidad? Esto suena como si estuviera reconfigurando uno de los pines SWD. Incluso hardfault no causaría este comportamiento.

Respuestas (1)

IDD_CNT_ENestá conectado al circuito de medición de potencia integrado. Si no se usa correctamente, interrumpirá temporalmente la fuente de alimentación V DD , reiniciando la MCU.

Mire los esquemas en el Manual del usuario

ingrese la descripción de la imagen aquí

El ajuste IDD_CNT_ENa salida baja inicia el temporizador externo U3. Después de un retraso de 150 ms, Q13o U3pasa a nivel alto, FET 1 in U20se apaga y la resistencia de derivación de 1 kΩ R22ahora está conectada en serie con V DD para mejorar la precisión de la medición de potencia. La MCU debe ponerse en modo de BAJA POTENCIA, PARADA o ESPERA, donde el consumo está muy por debajo de 1 mA, dentro de los 150 ms posteriores a la configuración IDD_CNT_ENen bajo, y volver a configurarla en menos de 150 ms después de que llegue la señal de activación en PA0.

Gracias berendi, Jan y Michel. Todos dieron en el clavo con el problema: era el conflicto del pin IDD_CNT_EN con la configuración como GPIO. Usar otro pin para GPIO funciona perfectamente. Problema resuelto. ¡Gracias de nuevo!
STM32L1xx HAL_GPIO_Init Problema
RespuestasAquíPolítica de privacidad1y, 0v