Arbitrary waveform by timer using DMA

> ARR and CCR set to 0 (initialized in source code)

ARR = 0 means, that the timer is stopped. As you also set ARR preload, and there is no Update event which would transfer the new ARR to the "active" register and start the timer, so it remains stopped.

JW

Update: seems that the silicon has a bug :( I used the Nucleo board reset button to restart and got the described behaviour. When doing a power reset it seems to (almost) work as expected.
I checked the errata sheet, but I couldn't find anything regarding the reset input only working partially...

Regards

> I expect the same behaviour when pressing the reset button or doing a power reset.

There are few things which behave differently upon power-on reset and NRST-reset. One of them is the PEMPTY bit behaviour, which is set if the FLASH is empty during reset (which may happen during programming after erase, depending on how exactly the programmer/debugger behaves), impacts the mapping at address 0, and is not reset by NRST, only by a power-on reset. The symptom involves the system-ROM (bootloader) being mapped at address 0, and usually interrupts then end up in the 0x1fffxxxx area. I guess there may be other mechanisms for different NRST/power-on behaviour. This is a recurring theme here, but rarely the user comes to a definitive conclusion.

How the pulse train ends depends on the PWM mode you are using, and the exact way how you end the pulse train and/or what do you exactly do with the output after the pulse train finishes. One way to tackle this is to set the last CCRx item to be 0 or ARR+1; those values should ensure the output to be a steady value of either polarity.

JW

Hello @RAltm 
>However, I indeed want to use non-circular mode. I want to output a varying number of pulses with varying period and pulse duration. Between the pulse trains, the output should stay low and the next pulse train must not start before the period of the last pulse of the previous train has expired

This task can be challenging if you want to achieve clean results.
Using DMA in normal mode typically generates a continuous PWM signal, with the last value in the pulse train remaining at the ARR. To generate a second pulse train, you must stop the PWM and restart it.

You can apply the following modifications to the previous project to address this use case:
The configuration creates a pulse train with values of 100, 150, and 175, then stops (with the PWM signal held low) until you start the timer with a new pulse train.

/* USER CODE BEGIN PD */
#define ARR_WAVEFORM_LEN (sizeof(arr_waveform) / sizeof(arr_waveform[0]))

/* USER CODE END PD */

/* USER CODE BEGIN PV */
volatile uint32_t dma_cndtr_start = 0;
volatile uint32_t dma_cndtr_now = 0;
volatile uint8_t dma_done = 0;
/* USER CODE END PV */

/* USER CODE BEGIN PFP */
void MyDMADoneCallback(DMA_HandleTypeDef *hdma);

/* USER CODE END PFP */

/* USER CODE BEGIN 2 */
 uint16_t arr_waveform[] = {100, 150, 175,175};

 __HAL_TIM_SET_AUTORELOAD(&htim16, arr_waveform[0]);
 __HAL_TIM_SET_COMPARE(&htim16, TIM_CHANNEL_1, 50);

 HAL_DMA_RegisterCallback(htim16.hdma[TIM_DMA_ID_CC1],
 HAL_DMA_XFER_CPLT_CB_ID,
 MyDMADoneCallback);

 if (HAL_DMA_Start_IT(htim16.hdma[TIM_DMA_ID_CC1],
 (uint32_t)(arr_waveform),
 (uint32_t)&TIM16->ARR,
 ARR_WAVEFORM_LEN) != HAL_OK)
 {
 Error_Handler();
 }

 __HAL_TIM_ENABLE_DMA(&htim16, TIM_DMA_CC1);

 if (HAL_TIM_PWM_Start(&htim16, TIM_CHANNEL_1) != HAL_OK)
 {
 Error_Handler();
 }

 if (HAL_TIM_Base_Start_IT(&htim16) != HAL_OK)
 {
 Error_Handler();
 }

 /* USER CODE END 2 */

/* USER CODE BEGIN 4 */

void MyDMADoneCallback(DMA_HandleTypeDef *hdma)
{
 dma_done = 1;
}
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
 if (htim->Instance == TIM16 && dma_done)
 {
 dma_done = 0;
 __HAL_TIM_DISABLE_DMA(&htim16, TIM_DMA_CC1);
 HAL_TIM_Base_Stop(&htim16);
 HAL_TIM_PWM_Stop(&htim16, TIM_CHANNEL_1);
 }
}
/* USER CODE END 4 */

verify that dma configuration in msp.c is like this :

void HAL_TIM_Base_MspInit(TIM_HandleTypeDef* htim_base)
{
 if(htim_base->Instance==TIM16)
 {
 /* USER CODE BEGIN TIM16_MspInit 0 */

 /* USER CODE END TIM16_MspInit 0 */
 /* Peripheral clock enable */
 __HAL_RCC_TIM16_CLK_ENABLE();

 /* TIM16 DMA Init */
 /* TIM16_CH1_UP Init */
 hdma_tim16_ch1_up.Instance = DMA1_Channel3;
 hdma_tim16_ch1_up.Init.Request = DMA_REQUEST_4;
 hdma_tim16_ch1_up.Init.Direction = DMA_MEMORY_TO_PERIPH;
 hdma_tim16_ch1_up.Init.PeriphInc = DMA_PINC_DISABLE;
 hdma_tim16_ch1_up.Init.MemInc = DMA_MINC_ENABLE;
 hdma_tim16_ch1_up.Init.PeriphDataAlignment = DMA_PDATAALIGN_HALFWORD;
 hdma_tim16_ch1_up.Init.MemDataAlignment = DMA_MDATAALIGN_HALFWORD;
 hdma_tim16_ch1_up.Init.Mode = DMA_NORMAL;
 hdma_tim16_ch1_up.Init.Priority = DMA_PRIORITY_LOW;
 if (HAL_DMA_Init(&hdma_tim16_ch1_up) != HAL_OK)
 {
 Error_Handler();
 }

 /* Several peripheral DMA handle pointers point to the same DMA handle.
 Be aware that there is only one channel to perform all the requested DMAs. */
 __HAL_LINKDMA(htim_base,hdma[TIM_DMA_ID_CC1],hdma_tim16_ch1_up);
 __HAL_LINKDMA(htim_base,hdma[TIM_DMA_ID_UPDATE],hdma_tim16_ch1_up);

 /* TIM16 interrupt Init */
 HAL_NVIC_SetPriority(TIM1_UP_TIM16_IRQn, 0, 0);
 HAL_NVIC_EnableIRQ(TIM1_UP_TIM16_IRQn);
 /* USER CODE BEGIN TIM16_MspInit 1 */

 /* USER CODE END TIM16_MspInit 1 */

 }

}

You should get a result like this :

BR
Gyessine

@waclawek.jan 
Update: I switched to a L082 device. Here, the reset behaviour after downloading is as expected. No need to do a power-reset as far as I can see by now. So, figuring out what's going on on the L432 device needs investigation.

Indeed the PEMPTY flag was set after download, but not always. So, the behaviour when doing a software reset if PEMPTY flag is set and cleared was more reliable, but it seems there's still other magic happening. Thanks again for pointing me to that detail. The code snippet I used:

if(0 != __HAL_FLASH_GET_FLAG(FLASH_FLAG_PEMPTY)) {
	SET_BIT(FLASH->SR, FLASH_FLAG_PEMPTY);	//bit is toggled when set
	NVIC_SystemReset();
}

@Gyessine 
Thank you for that detailed description and code snippets. Some questions:

• The variables dma_cndtr_start​ and dma_cndtr_now are defined, but not used. So I assume they're not relevant, right?
• The difference to using HAL_TIM_DMABurst_MultiWriteStart() function is that
  • the timer uses both IRQ and DMA setup
  • the timer interrupt fires on each period
  • only when the DMA is done the timer interrupt stops DMA and the timer itself
    Is the above true? If yes, it's done this way because it's easier to manage than by HAL_TIM_DMABurst_MultiWriteStart() function, right?

Regards

Hello @RAltm 

The variables defined in the private variables section are irrelevant. They were included for testing purposes and should have been removed. I apologize for the confusion.

I think your task is achievable using HAL_TIM_DMABurst_MultiWriteStart. However, this is not its main purpose. The main purpose of HAL_TIM_DMABurst_MultiWriteStart is to allow DMA to update a block of timer registers, not just one register. That is why I did not use it, but you can try it. It is a matter of preference, not correctness.

> I switched to an STM32L082 device. Here, the reset behavior after downloading is as expected. There is no need to perform a power reset as far as I can see. Investigating the reset behavior on the STM32L432 device is still required.

About this reported issue: it is different from the question you started this thread with. For moderation purposes, I suggest you post your new issue in a separate thread and close this thread if it is resolved or if you are now interested in your new question.
BR
Gyessine

Hello @RAltm 
Honestly, I recommend that you post the reset issue in a new thread. Explain the test scenario, the expected behavior, and the observed behavior in detail.
BR
Gyessine