This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

STM32F103 + PWM+ DMA +HAL problem?

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?

Parents
  • 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.

Reply
  • 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.

Children
No data