I have STM32F103 working on 8MHz. Use new ST HAL Driver (STM32CubeMX) + MDK-ARM v5.17? If I Init PWM on Ch1 Tim3
void MX_TIM3_Init(void) { TIM_ClockConfigTypeDef sClockSourceConfig; TIM_MasterConfigTypeDef sMasterConfig; TIM_OC_InitTypeDef sConfigOC; htim3.Instance = TIM3; htim3.Init.Prescaler = 0; htim3.Init.CounterMode = TIM_COUNTERMODE_UP; htim3.Init.Period = 9; htim3.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; HAL_TIM_Base_Init(&htim3); sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL; HAL_TIM_ConfigClockSource(&htim3, &sClockSourceConfig); HAL_TIM_PWM_Init(&htim3); sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET; sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE; HAL_TIMEx_MasterConfigSynchronization(&htim3, &sMasterConfig); sConfigOC.OCMode = TIM_OCMODE_PWM1; sConfigOC.Pulse = 1; sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode = TIM_OCFAST_DISABLE; HAL_TIM_PWM_ConfigChannel(&htim3, &sConfigOC, TIM_CHANNEL_1); } ... // Start PWM HAL_TIM_PWM_Start_IT(&htim3, TIM_CHANNEL_1);
all working OK and output generate 125ns pulse on 800kHz (1.25us) If replace Start_IT with DMA version
uint32_t pData[1]={6}; HAL_TIM_PWM_Start_DMA(&htim3, TIM_CHANNEL_1,pData,1);
all working OK and output generate 700ns pulse on 800kHz (1.25us),but if use
uint32_t pData[16]={3,3,3,3,3,3,3,3,0,0,0,0,0,0,0,0}; HAL_TIM_PWM_Start_DMA(&htim3, TIM_CHANNEL_1,pData,16);
this genreate 375ns its OK but frequency is 400kHz (2,5us) If I trace and look on reg CCR1 I see 3,0,3,0,3,0,3,0,3,0,3,0,3,0,3,0 What's wrong, what's the problem? Why is inserted 0 between 3?
Data needs to be 16-bit wide like the register, not 32-bit, where high-order 16-bit words are zero, thus alternating 3/0
Sure? That would indicate a grave error on the part of the library API designer. If the expected data format is really an array of 16 bit integers, then it's badly wrong for the function argument to be of type (uint32_t *).
Casting a pointer to a different type besides (void *) and (uint8_t *) just to pass it to a function, as suggested here, is almost always either superfluous or very wrong.