cancel
Showing results for 
Search instead for 
Did you mean: 

For the STM32F100V8T medium density device can I link TIM2 (master) to TIM15 (slave) using the internal trigger ITR0?

ash thorpe
Associate II

This seems to work fine (timer linkage used in my current firmware) but the Reference manual (Doc ID16188 Rev 5) suggests this internal trigger (ITR0) is not available in low & medium density devices?! 

Can I rely on all future batches of the STM32F100V8T MCU allowing this timer linkage, or should I look to combine two different timers? (I am already using most other timers, and I hope I do not need to change anything!)

The STM32 cubeMx tool seems to show that TIM15 ITR0 is available and can be configured on the STM32F100V8Tx MCU - see attached screen grab.

0690X000008A8WtQAK.jpg

I have some common code that is used to configure timer 2 and timer 15 to create linked microsecond and millisecond ticks. This initialisation code works fine, and links the timers as intended, despite the reference manual suggesting TIM15 ITR0 is not available.

/*Timer handles*/
static TIM_HandleTypeDef h_timUS;
static TIM_HandleTypeDef h_timMS;
 
bool initTimers(void)
{
    bool success = TRUE;
 
    TIM_MasterConfigTypeDef masterConfig;
    TIM_OC_InitTypeDef outputCompare_Config;
    TIM_SlaveConfigTypeDef slaveConfig;
 
    timerClockFrequencyHz = US_COUNTER_CLK;
 
    /* US_COUNTER - counts microseconds and resets at 1024 i.e. bits 1-10*/
    h_timUS.Instance = TIM2;
    h_timUS.Init.Prescaler = (US_COUNTER_CLK/1000000)-1;  /*23, as US_COUNTER_CLK = 24MHz*/
    h_timUS.Init.CounterMode = TIM_COUNTERMODE_UP;
    h_timUS.Init.Period = 0x3FF; /*reset at 1023*/
    h_timUS.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
    success &= (HAL_OK==HAL_TIM_OC_Init(&h_timUS));
 
    /*Master config*/
    masterConfig.MasterOutputTrigger = TIM_TRGO_OC1REF;
    masterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_ENABLE;
    success &= (HAL_OK==HAL_TIMEx_MasterConfigSynchronization(&h_timUS, &masterConfig));
 
    /*Output compare channel 1 config*/
    outputCompare_Config.OCMode = TIM_OCMODE_PWM1;
    outputCompare_Config.Pulse = 1;
    outputCompare_Config.OCPolarity = TIM_OCPOLARITY_HIGH;
    outputCompare_Config.OCFastMode = TIM_OCFAST_DISABLE;
    success &= (HAL_OK==HAL_TIM_PWM_ConfigChannel(&h_timUS, &outputCompare_Config, TIM_CHANNEL_1));
 
 
    /* MS_COUNTER - counts remaining bits (11-24)*/
    h_timMS.Instance = TIM15;
    h_timMS.Init.Prescaler = 0;
    h_timMS.Init.CounterMode = TIM_COUNTERMODE_UP;
    h_timMS.Init.Period = 0x3FFF;
    h_timMS.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
    success &= (HAL_OK==HAL_TIM_Base_Init(&h_timMS));
 
    /* Select the Input Triggers */
    slaveConfig.SlaveMode = TIM_SLAVEMODE_EXTERNAL1;
    slaveConfig.InputTrigger = TIM_TS_ITR0;
    success &= (HAL_OK==HAL_TIM_SlaveConfigSynchronization(&h_timMS, &slaveConfig));
 
    /* Initialise timer values to 0*/
    __HAL_TIM_SET_COUNTER(&h_timUS,0);
    __HAL_TIM_SET_COUNTER(&h_timMS,0);
 
    /* Enable timers */
    success &= (HAL_OK==HAL_TIM_Base_Start(&h_timMS));
    success &= (HAL_OK==HAL_TIM_OC_Start_IT(&h_timUS, TIM_CHANNEL_1));
 
    return success;
}

Reference manual extracts (Doc ID16188 Rev 5 page 420);

0690X000008A8YQQA0.jpg

2 REPLIES 2

I won't attempt to understand whether this is relevant to your case, but maybe it is:

https://community.st.com/s/question/0D50X00009XkejTSAR/stm32f100rct6tr-tim12-issues

JW

ash thorpe
Associate II

Thanks JW.

The STM32 MCU device ID is 0x420 (Rev_id = 0x1001), therefore this confirms I am looking at the correct Reference manual RM0041 (Doc ID16188).

The fact is my code works and links the timers exactly as I want, the cube tool suggests the timer linkage is valid, but the reference manual constraints seems to conflict with this.

TBH I am a fair way along with my development and don't want to change anything with these timers if I do not have too.

Kinda hoping someone from ST can confirm that I can ignore the Ref manual. Obviously though I don't want for the firmware to reach production and then find that the next batch of MCU's have different behavior.

I might look to raise a ST support ticket as this question is quite detailed.