How to move DMA ISR functions from flash to RAM? (hoping they run faster)

[Javier1]

Im using a stm32f105RBT6 and i am in need a ton of softpwm pins.

My solution (with the help of @Community member​ ) was to run 4 DMA channels triggered by 4 different timers addressing 4 different GPIO ports (in a circular mode).

This worked like a charm untill now.

Now i cannot use the external XTAL anymore, limiting the main clock down from 72Mhz to 36Mhz, this makes the softPWM of the DMA channel with the least priority to lack behind in frecuency.......

  

I dont know a lot yet about APB /AHB buses but :

The DMA1 should be completelly clogging the buses 

Links of interest:

• Moving ISR functions to RAM using chibios in a STM32H743xI
• Moving the NVIC table to RAM to create a bootoader

[Javier1]

CubeMX code uses both transfer halfdone and transfer done interrupts.

When DMA is set in circular mode.

Dont know why exactly , im still learning

My first guess was DMA clogging any of the internal APB buses not ISR problems.

[waclawek.jan]

What do you do in the interrupt?

Read out and check/post content of TIM and DMA registers.

JW

[Piranha]

Jan is asking what your code is doing in DMA interrupt callbacks. If nothing, then why do you have those interrupts at all?

[Piranha]

By the way, LTO (link time optimization) is a linker (not compiler) setting. It optimizing for speed decreases the speed, try optimizing for a size with Os+LTO.

> I cannot get rid of the entire HAL because i need to meet a realistic deadline

DMA initialization, starting, stopping - writing those functions takes less than 10 lines of code for each of them! It decreases the development time drastically contrary to endless fighting with Cube/HAL broken bloatware written by incompetent "developers".

[Javier1]

@Piranha​ CubeMX for some reason autogenerates ISR functions when DMA is activated

They prevent you from "unticking" the NVIC enable option.

I dont need them and i dont want them..

@Community member​ I placed some breakpoints in the ISR callbacks and they are never reached.... (probably because im using HAL_DMA_Start() instead of HAL_DMA_Start_IT() )

I just removed all ISR init code and callbacks ,the DMA still works as intended,The interruptions were not being triggered nor used.The original problem is still there but now i know , the issue is not in the ISR functions.

This is why Placing the Vector table in RAM was not improving performance.

Is there any way to debugg if the DMA is clogging memory buses? How to know if the buses/DMA are already at its limit.

[Javier1]

>try optimizing for a size with Os+LTO.

illl try that.

>writing those functions takes less than 10 lines of code for each of them! It decreases the development time drastically contrary to endless fighting with Cube/HAL broken bloatware written by incompetent "developers".

Then i need to figure out those 10 lines of code.(im on it)

[waclawek.jan · Accepted solution]

> How to know if the buses/DMA are already at its limit.

Decrease the timers period -> DMA rate.

But a few kHz DMA at 36MHz system clock should not be an issue. And it should not depend on optimization level, not the least. This is something else.

Are these 4 timer-triggered circular DMAs transferring from memory to GPIO, and nothing else?

JW

EDIT Oh, it's an 'F1... GPIO is behind an APB... that might be a bottleneck, and if software accesses peripherals on the same APB, it could be software-dependent indeed... and then even the "inverse" dependence makes sense - the better the software, the more APB is loaded and prevents DMA from working properly... so find what is loading the given APB bus in software (e.g. tight polling loops) and try to relieve on them.

[Javier1]

>Decrease the timers period -> DMA rate.

I have done that, the problem goes away when timers go down from 1,2Mhz to 1Mhz

>But a few kHz DMA

I just checked... Timers are running at 1,2Mhz to keep up with the resolution needed for the softpwm.

36Mhz/30(ARR)--> 1,2Mhz -->buffers are 160 words long--->softpwm of 7,5Khz

This might be the problem....

>Are these 4 timer-triggered circular DMAs transferring from memory to GPIO, and nothing else?

exactly

> if software accesses peripherals on the same APB,

Software accesses are not relevant, im not using them while testing right now, i am just software-setting the softpwms once and Starting DMAs.

> the better the software, the more APB is loaded and prevents DMA from working properly... so find what is loading the given APB bus in software (e.g. tight polling loops) and try to relieve on them.

Ill check on this anyway.

Edit: i just lowered the requirements of my system , timmers are now down to 900kHz and everything works