Anybody here using STM32F4xx parts ?

Yes, and setup the DMA but not with a timer.

Are you having any issues?

On 2019-06-12 boB wrote in comp.arch.embedded:

Well, I used the STM32F429, which is quite similar, not too long ago. And we use the M0 and M7 variants as well.

Do you have a specific question? As you are talking about timers and DMA, watch out for the following: DMA cannot reach the CCM (Core Coupled Memory).

I experienced this on an ST M7 part (which has more complicated bus structure). The Keil environment set the DTCM (Data Tightly Coupled Memory, as they call it there) as the default internal RAM as it is nice and fast and large enough for smallish projects.

But then when you want to send something using DMA (to a UART in my case) from an array in your code (RAM), it doesn't work. But using the same code, sending from FLASH does work!?!? --> DMA cannot reach DTCM, but can reach FLASH! Relocating the data array to another (slower, but reachable by DMA) SRAM block solved this problem.

Have a close look at "Memory and bus architecture" in document RM0090.

If you need DMA access to your C(?) code data but want your stack to be in CCM, you need to pay attention to the linker (scatter) file.

Never heared of a STM32F443.

There is a STM32F334 or a STM32F446 and many other STM32 parts.

-- Uwe Bonnes snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt

--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

I have done several projects using STM32F4xx for customers, for new things at the high end I'm using STM32M7 or H7 now.

Have you got a problem or are you just feeling lonely :-)

MK

Well, a little of both !

I was wrong above. It is a STM32F446VC part.

I am using DMA2 for A/D to memory and that's working fairly well.

TL;DR.... The issue I am having is that the documentation could be a bit better and there could be more examples akin to what I am doing or trying to do. I'm getting closer though to understanding how things work. More documentation and examples would be great and I have found a small bit that helps as well as some responses on the STM32 forum

I have a waveform table in RAM that needs to be DMA'd into two CCRx registers in TIM1 and TIM8. I have had TIM1 and TIM8 working well, each driving a full bridge in a timer interrupt but will need to vary the amount of time somewhat in-between CCRx updates by changing the RCR Repeat counter... At least until I can maybe get another timer trigger the updates maybe.

There are some restrictions in using this system though that may keep me from doing what I would like to do.

I would like to use the NDTR in DMA2 to trigger an interrupt when it is done so I can change the waveform there, if necessary.

I would also like to use the double buffer mode (DBM) SxM0AR and SxM1AR pointers to be able to change waveforms on the fly (M1 or M2 based on the CT bit)

BUT it looks like I can only use DBM only works in circular mode and the Transfer Complete intererupt (TCIF set) will not happen in circular mode. OK, so I guess I can change the waveform quickly in the TC interrupt and then restart the Timer and DMA.

And I also wanted to be able to use one data waveform table to be able to load interleaved data from memory to peripheral by setting the PINC to increment the peripheral and have it restart at the first PAR Peripheral Address again (CCRx1) but it appears that it will just keep incrementing the PAR peripheral address and stomp on registers above the CCRx4 register. That was an assumption I just learned about. Thought the BURST mode settings would take care of that. DUH !! Felt pretty stoopid there...

And then there is the DMAR/DMAB fields that from JW on the STM32 forum on ST's site says are a "window" to the data and not really something that I would actually write to. How this the DMAR logic actually works is a mystery to me.

So, yes, I'm getting things to work but very slowly because I appear to be the only one actually doing this, or at least I cannot find any working code to look at that does this, at least that is not CubeMX generated... CubeMX generated code is harder to follow for me than just setting bits directly, for example.....

DMA2_Stream5->CR |= DMA_SxCR_MINC;

I did start this project with CubeMX originally but did not set DMA to work in that environment. Then, when I started a new CubeMX project just to see what that generated DMA-TIM1 code looks like, it does not appear that those options I need are even available.

Everything I find online is pretty much just HAL code from CubeMX is all of the re-usable HAL calls and miscellaneous generated functions and typedef structures within structures, some pointers and some not.

The table showing the DMA1 and DMA2 triggers (I assume those are all triggers) are a bit weird too. For instance, DMA2 Stream 6, channel 0 gives me

TIM1_CH1 TIM1_CH2 TIM1_CH3

Why didn't they also add TIM1_CH4 since in TIM1, CC1DE through CC4DE should be able to enable or disable the DMA request. Right ? Or am I noit understanding that correctly ?

And Stream 4, Channel 6 offers... TIM1_CH4 TIM1_TRIG TIM1_COM

What would that be used for I wonder ? Still not sure what TIM1_COM is used for except maybe when there is a commutation on one (which one?) of the TIM1 outputs that happen to have positive and negative complementary outputs. It's not clear to me. Why do they put TIM1_CH4 away from TIM1_CH1, CH2 and CH3 ? More documentation on each one of these squares of choices would help me.

I am also using the IAR debugging screens in TIM1 and DMA2 to help figure out a lot of these bits. There are a LOT of bits though and not all of them are clear to me as to exactly how things work. I had no trouble in the 1980s using the old intel DMA controller on S100 bus !

So, yes,this does leave me a bit lonely too :)

Thanks for letting me bitch,

boB

On 2019-06-13 boB wrote in comp.arch.embedded:

The ST documentation is certainly not the worst processor documentention I've seen. But yes, it is sometimes hard to find a good example of the exact thing you try to do.

Setting double buffer mode automatically enables circular mode: "When the Double buffer mode is enabled, the Circular mode is automatically enabled (CIRC bit in DMA_SxCR is don?t care) and at each end of transaction, the memory pointers are swapped."

But the TC interrupt should work in DBM as well. At least it does on my M7 part and suppose this is true for the M4 as well.

In my application, I use the TC interrupt to set up the next buffer for the DBM and when all data is done, it turns off the peripheral (SPI in my case) and DMA.

One thing I ran into is that sometimes I got overuns on my peripherals, even with DMA and FIFO enabled. Turns out I had multiple DMA actions running and when the transfer length of a DMA was too long, it blocked other transfers. I decreased a block length somewhere, but can't remember the details unfortunately. But this may have been specific for teh M7 part and not a concern in the M4 part.

Similar here. Started with CubeMX, and still use it. But for some tasks you can not seem to set everything in cubeMX, so it is just easier (or the only way) to just code it yourself. So I use cubeMX for setting up most of the hardware (the clock config is so much easier in the MX graphical interface). But some stuff, like the DMA double buffer, I set up in my own code. In general, the DMA and interrupt transfer starting functions from MX are a bit hard to use (IMO). But you can use them as inspiration for your own code.

Yes, complexity and documentation size have increased a lot over 30 years.

But not as lonely as in the 80's, when you had no internet to look to for help. ;-)

But on the other hand, in those days you did have FAE's that came to your office and sat next to you trying to solve the problem. (Actually, that was in the early 90's for me, but suppose that was true for for the 80's as well).

Welcome! :-)

I've never attempted anything so ambitious with the DMA so I can't help directly with that. For quick and dirty projects I might well start with the CubeMX but I prefer to purge all the HAL stuff from production code once I work out what it's doing. I've never found the HAL approach to setting up DMA or ADCs to be as understandable as the chip documentation and if you bash the hardware directly it's faster and you can do anything you want.

MK

Yes, totally agree on that ! There is plenty enough flash memory in these parts where I can just keep the original HAL code generated by the CubeMX system in place but I won't re-use it because I can barely follow it in the first place. I'm not that good of a C programmer but I usually do understand the bits and bytes end of things as well as assembly language which is still necessary IMO for debugging purposes. But the documentation could use an extra sentence or two for many of these features.

I'm getting old but I refuse to let a few more complicated modes and bits get the best of me ! I've been doing this too long to let that happen. Iit is extremely hard to find good engineers to hire that understand this stuff, let alone the applications they are used for (power electronics).

Will post an update hopefully soon that may help oothers (and me)

boB

Well, I got it working at least to one CCRx TIM1 register.

I took JW's advice from the ST forum and got it to work first with no extra frills like bursts or FIFO or PINC features

Circular mode, which turns on automatically with double buffer mode turned on, appears to work as well, but I stop TIM1 and transfers in the Transfer Complete TC interrupt, do my business (to be done) and then re-enable things.

Now on to see if I can get two CCRx register DMA updates to work in TIM1 and TIM8 and keep my 3 ADC DMAs operational as well.