Can DMA transfer directly to FMAC memory on STM32G4?

[KHarb.1]

I want to use the FMAC to streamline weighted sum calculations using the FIR feature in non-circular mode. I have an array who's individual values are populated asynchronously via DMA and I use this array as the X1 buffer, but I missed that the buffer has to be within the FMAC local memory.

Loading the entire X1 buffer sequentially from already transferred values for each calculation hurts performance, so I'm hoping there's a way to do DMA transfers directly to the individual X1 FMAC memory locations. Is this possible?

[BarryWhit]

Of course you can DMA data to a peripheral address range. 

according to RM, even directly  from peripheral to peripheral. So what's the problem?

But in any case,

so, if you can partition the work into small enough pieces, you can do the DMA from SRAM to internal memory *while* the FMAC is doing its work. Just plain Jane Double-buffering, and that would work too (no drop in throughput).

 

[KHarb.1]

DMA to peripheral address range: I agree...but I don't think the FMAC's 'internal memory' is mapped like this. I figured there would simply be a base address, but there's nothing in the documentation other than the FMAC config registers.  Is there a mapped address space for FMAC memory?

Regarding the double buffering thing: I don't think that will work. X1 needs to be loaded by 16 writes to WDATA. This can be done with memory to memory DMA, but the FIR function appears to be disabled until all the values are loaded.

[BarryWhit]

> but I don't think the FMAC's 'internal memory' is mapped like this.

It must be accessible by DMA, if the processor can access it. there's no separate special bus only for FMAC. Let alone special  "Write to FMAC memory" instructions.

 

According to this presentation ,you can link the FMAC to a DMA channel, and have it "pull" data via DMA as need. That's probably what you want.

 

 

>  I don't think that will work. X1 needs to be loaded by 16 writes to WDATA

 

But you can split up the internal memory as you wish. You can remap the base address (relative offset *within* internal memory) before you start up the FMAC, and you change the size of the buffers you want FMAC to work on. I think this could totally work, but I have no experience that proves it.

 

see also this (warning of pitfall with access width) and this.

 

It seems almost every piece of documentation about FMAC uses DMA directly.  

 

Update:

So you already know about the WDATA register. At this point, I'm not quite sure what you're asking about.

Access to internal memory is through these WDATA/RDATA registers and an internal auto-incremented pointer. You can absolutely DMA to that peripheral register. 

Is your problem is that you want the DMA  transfers to be paced by the producer and not the consumer (FMAC)? that looks like something the CubeMX GUI can't help you with, but the hardware is probably capable of. 

 

@waclawek.jan  will know.

 

[KHarb.1]

I think a separate FMAC only bus may be kind of what's happening.  It seems a DMA request from the FMAC or a write to WDATA is the only way to get info into the FMAC internal memory.

DMA requests from FMAC won't suit my needs. I have data arriving asynchronously and from multiple timer triggers, so yes, DMA requests have to be handled by the producer.

I don't think CubeMX is the limiting factor...if there's a base address for the FMAC internal memory then everything will work just fine....

[BarryWhit]

> I think a separate FMAC only bus may be kind of what's happening. 

I'm pretty sure when FMAC is doing its "pull" thing via DMA, it is simply triggering a DMA request which ultimately results in a write to WDATA taking place over the bus. There is nothing magical going on.

 

> It seems a DMA request from the FMAC or a write to WDATA is the only way to get info into the FMAC internal memory.

 

Fine, and wouldn't a DMA write to WDATA triggered by the producer peripheral work?

 

Can you just tell us which peripheral it is btw? it'd be easier.

[KHarb.1]

I haven't tested, but setting up a 16 value DMA transfer where the source address is incremented and the destination isn't would implement the WDATA DMA write required.  However, this takes up time in an interrupt before the FIR operation can be executed.

Producer peripherals are 2x ADCs, 4x timers and 10x values loaded by software.  (FMAC is performing a weighted average rather than FIR.)

[BarryWhit]

They are both just dot products.

 

I'm afraid your setup is too complex for my meager abilities, and my suggestions seem to be missing their mark. My Apologies.