stm32cube HAL_IncTick() never called

[mail239955]

Posted on June 25, 2014 at 17:54

Hi,

I want to use the HAL_Delay() function from the stm32cube ''stm32f4xx_hal.c''. For proper functionality it requires the HAL_IncTick() to increase the ''uwTick'' variable. But where is the function that increases the variable ? It works when I initialize the HAL_SYSTICK_Config() by myself and count the ''uwTick'' via the SysTick_Handler() like . Is this the way it should be done ?

void
SysTick_Handler (void)
{
HAL_IncTick();
}

I assumed the HAL_Delay() should run out-of the box, just by calling it - am I wrong ? In the example projects for the ''stm32cube'' libs (e.g. GPIO_Toggle) it seems that HAL_Delay() runs without calling the SysTick_Config(). What am i missing here ? Please help

[joe]

Posted on June 25, 2014 at 18:51 You should have something like this at start of main():

/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* Configure the system clock */
SystemClock_Config();
/* System interrupt init*/
/* Sets the priority grouping field */
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0);
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_SDIO_SD_Init();
MX_USB_HOST_Init();

SystemClock_Config(); will configure you clock and then HAL_NVIC functions setup your interrupt for SysTick_IRQn. Then when the systick interrupt fires your interrupt handler (SysTick_Handler()) should be called, which increases the uwTick variable ( fires every 1ms ). If using MXCube ensure System tick timer interrupt is enabled. Does any of this look familiar to your source.

[mail239955]

Posted on June 25, 2014 at 21:06

Hi,

this sounds absolute familiar. My setup (all on linux): - Eclipse + Gnu-Arm-Plugin - st-flash util - stm32f429-discovery board Below see my simple code - what is missing ? The red LED does not turn on, and the green does not toggle. When ''//HAL_Delay(500);'' then the red LED turns on. I cannot find the function call of HAL_IncTick() in the libs. Can you point me to the function call ?

//
// This file is part of the GNU ARM Eclipse distribution.
// Copyright (c) 2014 Liviu Ionescu.
//
// ----------------------------------------------------------------------------
#include <stdio.h>
#include ''diag/Trace.h''
#include ''stm32f4xx.h''
#include ''stm32f4xx_hal.h''
#include ''stm32f4xx_hal_cortex.h''
// ----------------------------------------------------------------------------
//
// STM32F4 empty sample (trace via NONE).
//
// Trace support is enabled by adding the TRACE macro definition.
// By default the trace messages are forwarded to the NONE output,
// but can be rerouted to any device or completely suppressed, by
// changing the definitions required in system/src/diag/trace_impl.c
// (currently OS_USE_TRACE_ITM, OS_USE_TRACE_SEMIHOSTING_DEBUG/_STDOUT).
//
// ----- main() ---------------------------------------------------------------
int
main(
int
argc, 
char
* argv[])
{
// Call the CSMSIS system initialisation routine.
SystemInit();
// Initialise the HAL Library; it must be the first
// instruction to be executed in the main program.
HAL_Init();
/**
* @brief System Clock Configuration
* The system Clock is configured as follow :
* System Clock source = PLL (HSE)
* SYSCLK(Hz) = 168000000
* HCLK(Hz) = 168000000
* AHB Prescaler = 1
* APB1 Prescaler = 4
* APB2 Prescaler = 2
* HSE Frequency(Hz) = HSE_VALUE
* PLL_M = (HSE_VALUE/1000000u)
* PLL_N = 336
* PLL_P = 2
* PLL_Q = 7
* VDD(V) = 3.3
* Main regulator output voltage = Scale1 mode
* Flash Latency(WS) = 5
* @param None
* @retval None
*/
RCC_ClkInitTypeDef RCC_ClkInitStruct;
RCC_OscInitTypeDef RCC_OscInitStruct;
// Enable Power Control clock
__PWR_CLK_ENABLE();
// The voltage scaling allows optimizing the power consumption when the
// device is clocked below the maximum system frequency, to update the
// voltage scaling value regarding system frequency refer to product
// datasheet.
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
// Enable HSE Oscillator and activate PLL with HSE as source
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
// This assumes the HSE_VALUE is a multiple of 1MHz. If this is not
// your case, you have to recompute these PLL constants.
RCC_OscInitStruct.PLL.PLLM = (HSE_VALUE/1000000u);
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
// Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
// clocks dividers
RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK
| RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
// At this stage the system clock should have already been configured
// at high speed.
/*** GPIO INITIALIZATION ***/
GPIO_InitTypeDef GPIO_InitStructure;
// Enable GPIO Peripheral clock on Port G for LEDs
__GPIOG_CLK_ENABLE();
// Initialize green LEDs on PG13
// Configure pin in output push/pull mode
GPIO_InitStructure.Pin = GPIO_PIN_13;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
GPIO_InitStructure.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOG, &GPIO_InitStructure);
// Configure pin in output push/pull mode
GPIO_InitStructure.Pin = GPIO_PIN_14;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
GPIO_InitStructure.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOG, &GPIO_InitStructure);
//Don't know if I need this one
__SYSCFG_CLK_ENABLE();
/* Enable and set EXTI Line0 Interrupt to the lowest priority */
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0);
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
//initialize LED state
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_13, GPIO_PIN_RESET); 
// green LED OFF
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_14, GPIO_PIN_RESET); 
// red LED OFF
// Infinite loop
while
(1)
{
HAL_GPIO_TogglePin(GPIOG, GPIO_PIN_13); 
// green LED Toggle
//wait 500ms
HAL_Delay(500);
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_14, GPIO_PIN_SET); 
// red LED ON
}
}

[mail239955]

Posted on June 25, 2014 at 22:48

The same problem exists with the ''stm32cube'' - function ''HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)'' is never called when the interrupt occurs.

One has to manually call it using the CMSIS EXTI0 IRQ handler:

void EXTI0_IRQHandler(void) {

    HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0);

}

Then it works !

Is the stm32cube buggy ?

This complete stm32cube-hal setup does not make any sense to me, when such problems exist for the very basic functions, or am I missing something ?

[joe]

Posted on June 26, 2014 at 01:54

The above code has nothing obvious wrong with it. Do you have a file ''stm32f4xx_it.c'' ? This file should contain sys tick handler:

void SysTick_Handler(void)
{
HAL_IncTick();
HAL_SYSTICK_IRQHandler();
}

TheHAL_IncTick function is called from file stm32f4xx_hal.c I'm using MDK4.73 but I presume you should have the same files. I also set the option for seperate .h/.c file but don't think thats related. Not sure what's happening with you EXT interrupt. Is the ''!= RESET'' condition being satisfied? Can you check by setting break and stepping through.

[mail239955]

Posted on June 26, 2014 at 09:28

I can see the light now ....

Indeed I was missing the ''stm32f4xx_it.c'' from the project folder of the ''stm32cube'' example.

But does it make sense, that in the HAL-librariy ''stm32f4xx_hal.c'' are functions defined (e.g. HAL_IncTick() ) that require a local definition/connection to the CMSIS function ?

What you tell me, is that I have to make this connection to CMSIS locally. I expected the ''stm32cube'' libs to provide these connections to CMSIS functions.

When I look into the GPIO_EXTI example, I see that there is also

a ''stm32f4xx_it.c'', but of course with other content.

Please teach me, why this does make sense. I dont see the sense in it at the moment - but I want to learn .....

[toannds]

Posted on July 14, 2014 at 19:09

I'm a beginner and got the same issue. However, it seems to be the way we should implement. The stm32f4xx_it.c contains handlers which should be implemented by user. For instance, the SysTick_Handler() should call HAL_SYSTICK_IRQHandler() which is defined in stm32f4xx_hal_cortex.c. The later in turn calls the user defined HAL_SYSTICK_Callback() if there is one. Otherwise, it calls the __weak void HAL_SYSTICK_Callback(void) in the same file, which does nothing.

This could be confirmed by User Manual UM1725 ''Description of STM32F4xx HAL drivers''. When come to GPIO, Page 47 written:

''When selecting EXTI mode with interrupt generation, the user must call

HAL_GPIO_EXTI_IRQHandler() from stm32f4xx_it.c and implement

HAL_GPIO_EXTI_Callback()''

From: hwe

Posted: Thursday, June 26, 2014 9:28 AM

Subject: stm32cube HAL_IncTick() never called

I can see the light now ....

Indeed I was missing the ''stm32f4xx_it.c'' from the project folder of the ''stm32cube'' example.

But does it make sense, that in the HAL-librariy ''stm32f4xx_hal.c'' are functions defined (e.g. HAL_IncTick() ) that require a local definition/connection to the CMSIS function ?

What you tell me, is that I have to make this connection to CMSIS locally. I expected the ''stm32cube'' libs to provide these connections to CMSIS functions.

When I look into the GPIO_EXTI example, I see that there is also

a ''stm32f4xx_it.c'', but of course with other content.

Please teach me, why this does make sense. I dont see the sense in it at the moment - but I want to learn .....