Arbitrary waveform by timer using DMA

[RAltm]

Hello,

I want to generate an arbitrary waveform by a timer using DMA. The waveform is using different pulse widths and also varying periods in multiples of 25µs.

By reading AN4776 and HAL documentation I figured out it should be possible with HAL_TIM_DMABurst_MultiWriteStart() function. Unfortunately I don't get an output signal except after reset where a short pulse can be seen. I assume this pulse is due to port configuration during initialization. After that pulse, the signal stays high.

My setup (CubeMX):

• Nucleo32-L432, core clock 80MHz
• Used timer is Tim16
  • Prescaler is set to 399 => 80 MHz / 400 = 5µs resolution
  • ARR and CCR preload enabled
  • ARR and CCR set to 0 (initialized in source code)
  • DMA enabled
    • normal mode
    • memory to peripheral
    • Word / Word
    • increment address on memory
    • interrupt enabled

For a first run I want to use fixed pulse widths and varying periods, so all my code does is the following:

/* USER CODE BEGIN 2 */
htim16.Instance->ARR = 39;	//40 * 5µs = 200µs period
htim16.Instance->CCR1 = 4;	//5 * 5µs = 25µs pulse
HAL_TIM_DMABurst_MultiWriteStart(&htim16, TIM_DMABASE_ARR, TIM_DMA_UPDATE, (uint32_t *) Buffer, TIM_DMABURSTLENGTH_1TRANSFER, sizeof(Buffer) / sizeof(Buffer[0]));
HAL_TIM_PWM_Start(&htim16, TIM_CHANNEL_1);
/* USER CODE END 2 */

As far as I understood I need to initiate the first pulse by calling HAL_TIM_PWM_Start() and HAL_TIM_DMABurst_MultiWriteStart() setup the DMA to handle the subsequent transfers. 

When running that code, I get a single pulse of ~3.4µs at a period of 5.8µs, after that the output stays high. Since this is my first encounter with DMA I'm a bit lost. I don't get what I'm missing because other forum entries use basically the same approach as far as I can see.

Regards

[RAltm]

@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

[Gyessine]

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

[RAltm]

Hello Gyessine,

as I wrote here I also want to change the pulse width, I just started with one register to keep it as easy as possible. So I'll try to adapt your approach to HAL_TIM_DMABurst_MultiWriteStart. Your examples gave a good insight, thank you for that.

Regarding the reported issue: basically it wasn't a software issue, but the device behaviour which caused the issue. So, I agree that different issues shouldn't be mixed, although we did it by focusing on DMA handling, not the reset issue.
Question: shall I modify the topic title to better reflect that it's been related to device behaviour or should I really create a new topic especially for the reset behaviour?

If we agree that the real issue is the reset behaviour of the L432, there's no solution yet. If we decide that the goal of having a working DMA transfer has been reached, I can mark one of the postings as solution (currently I don't care if it works on L432 or L082) and I create a new topic about the reset stuff. I any case I think it would need pointing someone from ST to it.

Regards

[waclawek.jan]

> reset behaviour of the L432, there's no solution yet

Before enabling any interrupt (i.e. in startup or very beginning of main()):

- set SCB_VTOR to 0x0800'0000 - there may be some Cube-specific way to do that, as I've said, I don't use Cube

- set SYSCFG_MEMRMP.MEM_MODE to 0b000 to explicitly map main FLASH to 0x0000'0000

JW

[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