Differences on MX_TIMx_INIT()

[FRest.1]

I've found a significant difference in the function MX_TIMx_init() function generated from STM32 development tool for two different platforms. The first (it work) is generated for NUCLEO-F413ZH the second (it doesn't work) is generated for NUCLEO-WL55JC1 (LoRaWAN End Node). On the second one, the clock seems not initialized.

First code:

void MX_TIM16_Init(void)
{
 
 /* USER CODE BEGIN TIM16_Init 0 */
 
 /* USER CODE END TIM16_Init 0 */
 
 /* USER CODE BEGIN TIM16_Init 1 */
 
 /* USER CODE END TIM16_Init 1 */
 htim16.Instance = TIM16;
 htim16.Init.Prescaler = 48-1;
 htim16.Init.CounterMode = TIM_COUNTERMODE_UP;
 htim16.Init.Period = 65535;
 htim16.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
 htim16.Init.RepetitionCounter = 0;
 htim16.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;
 if (HAL_TIM_Base_Init(&htim16) != HAL_OK)
 {
 Error_Handler();
 }
 /* USER CODE BEGIN TIM16_Init 2 */
 
 /* USER CODE END TIM16_Init 2 */
 
}

Second code:

static void MX_TIM4_Init(void) {
 
	/* USER CODE BEGIN TIM4_Init 0 */
 
	/* USER CODE END TIM4_Init 0 */
 
	TIM_ClockConfigTypeDef sClockSourceConfig = { 0 };
	TIM_MasterConfigTypeDef sMasterConfig = { 0 };
	TIM_IC_InitTypeDef sConfigIC = { 0 };
 
	/* USER CODE BEGIN TIM4_Init 1 */
 
	/* USER CODE END TIM4_Init 1 */
	htim4.Instance = TIM4;
	htim4.Init.Prescaler = 96 - 1;
	htim4.Init.CounterMode = TIM_COUNTERMODE_UP;
	htim4.Init.Period = 65535;
	htim4.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
	htim4.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;
	if (HAL_TIM_Base_Init(&htim4) != HAL_OK) {
		Error_Handler();
	}
	sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL;
	if (HAL_TIM_ConfigClockSource(&htim4, &sClockSourceConfig) != HAL_OK) {
		Error_Handler();
	}
	if (HAL_TIM_IC_Init(&htim4) != HAL_OK) {
		Error_Handler();
	}
	sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
	sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
	if (HAL_TIMEx_MasterConfigSynchronization(&htim4, &sMasterConfig)
			!= HAL_OK) {
		Error_Handler();
	}
	sConfigIC.ICPolarity = TIM_INPUTCHANNELPOLARITY_BOTHEDGE;
	sConfigIC.ICSelection = TIM_ICSELECTION_DIRECTTI;
	sConfigIC.ICPrescaler = TIM_ICPSC_DIV1;
	sConfigIC.ICFilter = 0;
	if (HAL_TIM_IC_ConfigChannel(&htim4, &sConfigIC, TIM_CHANNEL_1) != HAL_OK) {
		Error_Handler();
	}
	/* USER CODE BEGIN TIM4_Init 2 */
 
	/* USER CODE END TIM4_Init 2 */
 
}

I imagine this is by design, but I'd like to understand why.

Someone can explain me?

F.

[Tesla DeLorean]

First clearly isn't being configured for Input Capture, so would seem it is reflective of what functionality you check-boxed in the tools.

The clock for the TIM is often enabled in the MSP code called by the TIM Init code.

The F4 likely also has a less complicated clock tree

>>it doesn't work..

In what specific sense? The first simply enables the TIM to count maximally from the APB's TIMCLK source.

Pretty sure the second will clock similarly, what's going on with TIM4->CNT ?

[FRest.1]

Thank Tesla for your reply.

I use the same code.

I need to generate a pulse of 10 uS using a uS based timer.

First I've tested the code on NUCLEO-F413ZH, and it works (I'm using STM32CubeIDE).

Then I have coded it on NUCLEO-WL55JC1, but no all functions are generated in the same mode. For example on the second platform, the GPIO init code is not generated and I had to implement it.

I suspect the same thing for the timers. The source clock seems not defined. For every delay I've set, for pulse duration, its width is the same.

Now I'm trying to add a clock source (HAL_TIM_ConfigClockSourse()).

This is my code:

MX_TIM4_Init();
/* USER CODE BEGIN 2 */
// Start timer 3
HAL_TIM_IC_Start_IT(&htim4, TIM_CHANNEL_1);
 
while (1) {
HAL_GPIO_WritePin(Trigger_GPIO_Port, Trigger_Pin, GPIO_PIN_SET);
	__HAL_TIM_SET_COUNTER(&htim4, 0);
	while (__HAL_TIM_GET_COUNTER(&htim4) < 10) // almeno 10 uS
		;
 
	HAL_GPIO_WritePin(Trigger_GPIO_Port, Trigger_Pin, GPIO_PIN_RESET);
	HAL_Delay(1000);
 
		/* USER CODE END WHILE */
 
		/* USER CODE BEGIN 3 */
	}
	/* USER CODE END 3	
 

Sorry, I'm a beginner on the STM32 platform and many things escape me.

F.

[TDK]

> This is my code:

Does it work? If not, what did you expect it to do and how does it behave instead?

> For every delay I've set, for pulse duration, its width is the same.

If it works at all, that would suggest the timer is counting. If you change the "10" to "100" in your code, you're saying the delay doesn't change? What delay is it?

Note that there are better ways to generate a 10us pulse without the use of the CPU. Timers have a PWM mode.

[FRest.1]

> Does it work?

it works on NUCLEO-F413ZH but not on NUCLEO-WL55JC1

> What delay is it?

It is about 6 uS for delay from 10 to 200 and it became 42 uS with delay equal 2000 :(

But I need to be more precise. The routine is inserted into LoRaWAN end-node code (starting from the STM32CubeWL code example). Now, after some tests, the delay routine (TIM initialization and so on) works if I exclude all LoRaWAN processes and have the strange behavior with LoRaWAN initialized.

So, I think that there is a conflict with the LoRa code setting, but I'm not able to find where. :worried_face: :confounded_face: Uffa.

F.

[FRest.1]

Ok, the problem seems to be the power management. If I disable it using

#define LOW_POWER_DISABLE 1

on sys_conf.h the timer works, now I have to understand how to disable dynamically the low power for the time needed for my routine.

It's not very clear, even reading the documentation.

Any suggestion is appreciated.

 F.