cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G431KB DAC DMA not working

PBieg.1
Associate II

Trying to get a basic sample DAC1 with DMA, triggered by TIM2 working.

This should be trivial, works fine on SMT32F3. I'm using a Nucleo-32 SMT32G431.

Using Cube IDE. The only non IDE-generated code in main is:

  /* USER CODE BEGIN 2 */
 
  static uint16_t x[4];
  x[0]= 100;
  x[1]= 1000;
  x[2]= 2000;
  x[3]= 3000;
 
  HAL_TIM_Base_Start_IT(&htim2);
  HAL_DAC_Start_DMA(&hdac1, DAC_CHANNEL_1, (uint32_t*)x, 4, DAC_ALIGN_12B_R);
 
  /* USER CODE END 2 */

IOC configuration:

  • DAC with output buffer (verified, works fine in non-DMA mode)
  • circular DMA buffer, 1/2 word
  • trigger: TIM2 update
  • TIM2: set to count up to 500, internal clock (works, verified by reading the clock)

Compared to some DAC/DMA examples - everything seems fine (and works on a Nucleo-32 SMT32F3. Please help - this is extremely frustrating and has held up a a project for 3 days.

test1.ioc and main.c files attached.

Thank you!

Paul

21 REPLIES 21
PBieg.1
Associate II

Additional piece of information: it appears to throw a DMA transfer error for no obvious reason.

Read out and check/post the relevant TIM, DMAMUX, DMA and perhaps also DAC and GPIO registers' content.

JW

RMcCa
Senior II

(Uint32_t *)x doesn't look right to me. The DMA wants the 32bit base address of the array. Try (uint32_t)&x[0] instead.

The DMAMUX documentation is not very helpful and HAL (and CUBE IDE) seems to basically ignore it. Does anything need to be set in DMAMUX beyond what HAL would set automatically?

It's the same thing (this is C :-), but thanks for looking.

The challenge is knowing what is relevant - the promise HAL makes is not having to know. Otherwise might as well go bare metal, which given the state of the documentation seems best avoided.

> The challenge is knowing what is relevant -

Then read it and post all.

> the promise HAL makes is not having to know.

You don't need to know but then you also don't demand it to work.

> Otherwise might as well go bare metal, which given the state of the documentation seems best avoided.

Yeah, because Cube/HAL documentation is so great.

JW

> the promise HAL makes is not having to know.

Where does it make that promise?

berendi
Principal

What is the problem with the DMAMUX documentation? Do you have the latest revision (Rev 4) of the reference manual?

What information is missing?

Please post the contents of the peripheral registers of all peripherals involved, RCC, TIM2, DAC, GPIO, DMA1, DMAMUX.

> this is extremely frustrating and has held up a a project for 3 days.

That's why my policy is to forget HAL the moment something does not work. 3 days should be enough to get a DMA transfer working based on the reference manual.