NUCLEO H745ZI can't use DMA for DAC like shown in examples online with M7, only M4

[dshekter1]

SOLUTION

Buffer was being put into DTCM by cube. Ensure it doesn't do that, and you should be set.

I want to start by saying that it works on the M4, but not on the M7 and I don't know why. The M7 on pretty much all the peripheral configurations I've seen is that purple-ish "hey don't do this" colour, but it doesn't say why.

I am trying to follow the examples

here

here (with writeup here)

and here

but they're all pretty much "configure and run it. observe success"

I keep getting an underrun error on the DAC. I saw this post from a G4, but I'm already set to word length transfers.

I've confirmed in manually sending DAC values that the pins are configured, and I do see 0v instead of floating once the modules are initialized. But I'm always getting an underrun error, even when I slow the timer way down. Which leads me to believe that like in the G4 post it's not an inability to keep up, it's an inability to do any transfers. I wouldn't be surprised if I'm missing something because this is a dual core chip, but I've verified that the M7 does make it through initialization with no issues. So far I have confirmed:

Before DAC_Start_DMA:

• DAC
  • disabled
  • trigger enabled
  • trigger configured for TIM2 (as wanted)
  • everything else 0 except CCR and the SHHR & SHRR registers
• TIM2
  • prescaler set to f_clk in MHZ - 1
  • ARR set to 999, to hopefully make 1 KHz update events
  • CR1 shows it's disabled (all 0s)
  • MMS indicates on trigger out it'll send an update event (desired)
  • UIF set in SR, no interrupt enabled though so should be fine to leave it
• DMA1, stream 0
  • FIFO status = 4 = empty (expected), FIFO disabled
  • Priority level high (one example was able to use low and nothing is running so should be fine)
  • MSIZE = PSIZE = 2
  • MINC = 1, PINC = 0, CIRC = 1, DIR = 1 (memory->peripheral)
• DMAMUX1
  • C0CR = 67, have verified that is DAC channel 1's DMA signal

After DAC_Start_DMA:

• DAC only CR changed:
  • channel1 enabled
  • trigger enabled
  • DMA enabled
  • underrun interrupt enabled
• TIM2
  • unchanged (CNT still 0 because haven't started it yet)
• DMA1
  • EN still 0
  • TCIE = HTIE = DMEIE = 1
  • NDTR is expected
  • PAR = 0x40007408 = DAC1->DHR12R1(desired)
  • M0AR = 0x200000b8 = start of sample table
• DMAMUX1
  • same

After TIM_Base_Start

• DAC
  • indicated underrun in SR
• TIM2
  • CEN set
  • SR has all CC's now set because they were left at 0
  • CNT now 0x16b
  • DMAR = 0x1. not sure if this is important as "trigger DMA request enable" in DIER = 0
• DMA1
  • EN still 0, so all still same
• DMAMUX1
  • still routing request 67 to channel 0

So I'm kind of at a loss on this one. Manually setting the enable bit in S0CR doesn't do anything, in fact the SFRs view still shows it as 0. I've tried a clean project. All clocks set to 80 MHz. Any ideas? I suppose I could dump the configs of the registers, but I'm suspecting there's something in the difference between the M4 and the M7's accessing of the peripherals since they look the same on the surface. I could also try and read the entire memory peripheral memory map, but I'm worried there'll be a write only register that'll hardfault me or something.

[TSimo.1]

I am using the NUCLEO H745ZI and having the same problem using DMA with the DAC on M7, but I had not tried M4 until I saw your post. I am following the same examples you mentioned. I just tried the example on M4 and it worked. So, the problem definitely seems to be something about M7.

The only thing that I have read that may provide an explanation is this: https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices I do not understand the article well enough to figure out if this is the problem and how to develop a work-around. Maybe you understand it well enough to come up with a solution. If you do, please post it so I can use it.

[dshekter1]

Given it's been almost 2 months I didn't figure this would get any attention, but I did actually find a solution.

If you note the memory address of the buffer, you'll note it fits this bullet point from that link:

"Memory placed in DTCM RAM for D1/D2 peripherals"

I believe the solution is to make a custom linker file, though I just let the M4 handle it.

At least that was my issue. I'll edit this post with the solution for anyone else who finds it.

[Tesla DeLorean]

The M7 side DMA would need visibility into the memory used, the bus matrix diagram should be illustrative. Perhaps looks at working H743 examples.

M7 side DTCMRAM definitely isn't something I'd expect to work.

Use RAM in the D2 0x30000000..0x30047FFF range, enable the D2 SRAM clocks

[dshekter1]

It was as soon as I saw it, I had just never considered that as an issue. For my other work on the H745 I'm using a different IDE that places things in the D2's SRAM by default for compatibility over performance. Now that I know cube uses the DTCM, I was able to fix it.