STM32L1xx HAL_GPIO_Init Problem

I am developing an application for a University project on my STM32L1DISCO board with the STM32L152RC MCU.

I have configured the pins and generated the init code via STM32CubeMX. I am using Atollic TrueSTUDIO as the IDE.

The problem is that the generated init code cannot run on my MCU. After spending a lot of time on debugging I found that the problem in the code is this one line using the HAL gpio library:

HAL_GPIO_Init(IDD_CNT_EN_GPIO_Port, &GPIO_InitStruct);

Even though the preceding code is correct,

  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;


After stepping through the code line-by-line during debugging, I found that the HAL GPIO Init function does not execute and instead gives the runtime error: "Target not Responding, retrying...".

When I comment the HAL GPIO Init line, the program runs through with no issues.

STM32CubeMX includes the HAL library in the code. On top there is,

include "stm32l1xx_hal.h"

So, I'm not sure what's causing the issue I'm seeing. I would really appreciate your help on this as I don't know what to try next.

Thank you.

• You should step into the code of the init function and check deeper what can be wrong. What I also had one time, but was not related to GPIO pins directly, was that in STM32CubeMx, in Sys, Debug was not set to Serial Wire. This caused that suddenly debugging / connection lost came up during intialisation. – Michel Keijzers Mar 17 '18 at 22:40
• Hi Michel, thanks for the comment. I tried your suggestion and found the culprit to be this set of code within the HAL_GPIO_Init function: /* Configure IO Direction mode (Input, Output, Alternate or Analog) */ temp = GPIOx->MODER; CLEAR_BIT(temp, GPIO_MODER_MODER0 << (position * 2)); SET_BIT(temp, (GPIO_Init->Mode & GPIO_MODE) << (position * 2)); GPIOx->MODER = temp; Any idea on why these lines of code may be problematic for the MCU? – Rishabh Kumar Mar 18 '18 at 3:29
• No, sorry, I haven't dived in so much... are you sure you used the correct board/CPU type in CubeMx? You also can try another GPIO pin (maybe there's a conflict somewhere). – Michel Keijzers Mar 18 '18 at 11:07
• Which pin is that IDD_CNT_EN_GPIO? PA13 or PA14 by any chance? This sounds like you are reconfiguring one of the SWD pins. Even hardfault would not cause this behaviour. – Jan Dorniak Mar 18 '18 at 13:42

IDD_CNT_EN is connected to the onboard power measurement circuitry. If not used properly, it will temporarily disrupt VDD power supply, resetting the MCU.
Setting IDD_CNT_EN to output low starts the external timer U3. After a delay of 150 ms, Q13 of U3 goes high, FET 1 in U20 is switched off, and the 1kΩ shunt resistor R22 is now connected in series with VDD to improve the accuracy of the power measurement. The MCU should put itself to LOWPOWER, STOP or STANDBY mode, where consumption is well below 1 mA, within 150 ms of setting IDD_CNT_EN to low, and set it back to high in less than 150 ms after the wakeup signal on PA0 arrives.