2
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ 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. \$\endgroup\$
    – Michel Keijzers
    Commented Mar 17, 2018 at 22:40
  • \$\begingroup\$ 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? \$\endgroup\$
    – Rishabh Kumar
    Commented Mar 18, 2018 at 3:29
  • \$\begingroup\$ 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). \$\endgroup\$
    – Michel Keijzers
    Commented Mar 18, 2018 at 11:07
  • \$\begingroup\$ 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. \$\endgroup\$
    – jaskij
    Commented Mar 18, 2018 at 13:42

1 Answer 1

Reset to default
2
\$\begingroup\$

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.

Look at the schematics in the User Manual

enter image description here

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.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks berendi, Jan, and Michel. You all hit the problem on the nail: it was the IDD_CNT_EN pin conflict with being set as GPIO. Using another pin for GPIO works perfectly. Problem resolved. Thanks again! \$\endgroup\$
    – Rishabh Kumar
    Commented Mar 20, 2018 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.