Warning: limit simultaneous DMAs to 2

Posted on January 15, 2012 at 11:20

Hi,

I have been unable to reproduce the problem so far. I wrote a test application using 3 SPIs and 1 ADC running continuously and using DMAs, 7 DMA streams in use together, I'll add more later (I2C and SDIO).

The test

http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery:testdma

.

The application does not detect DMA errors or DMA timeouts (SPI operations are guarded by timers looking for missing TCs, DMA errors halt the system and the LED would stop flashing).

Could you share a test case?

BTW, your blog is very interesting.

Giovanni

---

http://www.chibios.org

Posted on January 17, 2012 at 03:00

I'm following this thread with interest, as I've grown quite fond of the DMA ''capability''.

So, what do I convert to interrupt:

• SDIO - No way - 6,000,000 interrupts per second.
• ADC 1 + 3 - Not happy - 120,000 interrupts per second, but I need both channels due to the allocation of my pins. The down side of the ADC's is they have no FIFO, and only 1 shared (between the inputs, not the ADC's) data register :(
• SPI2 - Possible - <10,000 interrupts per second. Once again no FIFO on the data register :(
• Memory-to-memory copy - So sad - guess I'll just have to stick with memcpy.
• UARTS - I was going to write them as DMA (because it's there), guess I'll stick with interrupt driven for now. 

I can probably redesign the software to have different operational modes - each allocating the DMA units differently. That just means I've got to write some of the low level drivers again, and be able to switch between the different modes.

I hope that ST can find a work-around - which in some ways would be better than a fix, because otherwise I will have to write multi-silicon code.

Posted on January 20, 2012 at 09:30

I've noticed this thread slipping down the list. The question seems so important (to me) that I'm surprised ST haven't leapt to the defence of their STM32 designs.

Frank - If you discover why you think more than 2 DMA doesn't always work and why Giovanni finds it does, I hope you'll explain on your excellent blog.

I'm particularly interested as I hope to use (on STM32F4XX) the camera and SDIO with DMA as well as USARTS - although maybe not at the same time given what you've written.

thanks ...

Posted on January 21, 2012 at 10:55

I updated my test application (

http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery:testdma

) by adding two continuous memory to memory DMA copy operations in background (at lowest DMA priority), nine DMA streams total. All DMA operations are guarded by watchdog software timers in order to catch missing DMA events, it is running since yesterday and still nothing.

Now, my application does not use the ST FW library but a different framework so I wonder if there could be a software issue involved or some side effect triggered by something I am not using in my test case.

Giovanni

---

http://www.chibios.org

Posted on January 22, 2012 at 17:21

I have a lot of questions about this as well - certainly I don't fully understand it at all. On our hardware it is clear, however you'd need an image sensor on the DCMI port to be able to replicate it (plus an SD card although those are more common). I also have an email from ST saying they've replicated the problem so it's not just us. I cannot publicly distribute our piece of code because it's a portion of our application. I have tried all manner of things to find a ''software'' reason for this behaviour, but haven't succeeded - it really does appear to be hardware.

I would like to create a more ''general purpose'' testcase which replicates this problem. Ideally something that doesn't involve the DCMI port because that's a less commonly used port (and every image sensor is different). At the moment I'm tied up with some other work so it's not going to happen in the immediate future. It is on my list of things to do.

Posted on January 22, 2012 at 23:42

Hi Franck,

 

We confirm your findings and it is a limitation that concerns only our DMA2, and here is the detailed description :

DMA2 controller could corrupt data when managing AHB and APB2 peripherals in a concurrent way :

Description :

This case is somehow critical for peripherals embedding FIFO and generates data corruption. For memories, the impact is a multiple access but the data is not corrupted. AHB Peripherals embedding FIFO are DCMI, CRYPT, HASH. on STM32F2/40xx  without CRYPTO only the DCMI is impacted.

Implications:

The data transferred by the DMA to the AHB peripherals could be corrupted in case

of a FIFO target or multiply accesses in case of memories access.

Workarounds :

Avoid concurrent AHB and APB2 transfer using DMA2. One of the following approach could be used to solve the issue:

• If DMA2 is used to manage AHB peripheral (DCMI, CRYPT, HASH), we can use the Cortex-M CPU to manage APB2 peripherals.

• If DMA2 is used to manage APB2 peripheral, we can use the CPU to manage AHB peripheral (DCMI, CRYPT, HASH).

Obviously, we will update our errata on web soon .

Thank you again for your findings .

Cheers,

STOne-32  { STM32 moderator }

PS:

You have a really Nice blog.  

Posted on January 23, 2012 at 15:58

Hi STOne-32,

Would you kindly explain, what CCI, in STM32F4 context, means ?

I just searched  RM0090 throughly, followed by Google search for this term.

Zero, null, nada results found...

Regards

Jacek

Posted on January 23, 2012 at 16:24

Would you kindly explain, what CCI, in STM32F4 context, means ?

CMOS/CCD Camera Interface = DCMI

Posted on January 23, 2012 at 18:27

Hi Jacek,

Sorry for the typo it should DCMI not CCI.  The post was updated below.

Cheers,

STOne-32.

Posted on January 24, 2012 at 05:41

Hi ST1,

Thank you very much for the information - it's much appreciated. Pretty obviously, if we understand the problem then we can be in a position to work around it, so your information is incredibly valuable.

I'm a little puzzled because your description of the problem doesn't seem to really explain what we've been seeing.

The biggest puzzlement is you mention that data can be corrupted. I don't know if we've seen corrupted data (we currently have no way to verify the data coming from the image sensor on the DCMI port, so if the data has been corrupted it's not really visible to us). What I do know is we've seen the DMA transfers simply stop. In the case of both the ADC and the SDIO, we've seen them stop running in mid-transfer. So this isn't a corruption of data - this is a cessation of data. From your understanding, is it possible for this problem to cause the DMA to simply stop servicing a stream? (Or is there some other way that the DMA can stop - perhaps the DMA can do something to cause the peripheral to error or to ''lock up'' somehow?)  This issue with the DMA unexpectedly stopping on a stream was of course the symptom that originally lead us all down this road.

My second question is, I interpret your message as being (among other things): ''Do not have the DCMI and the SDIO running under DMA at the same time.''  Because the DCMI is on the AHB and the SDIO is on the APB2.  Is this correct - this is a combination we should avoid?

I ask because this is the combination we have running now, and we have no problem with it that I'm aware of. Having said that, we might have data corruption and not know it (my previous comment about DCMI image sensor data applies here). However I do know we have no ''DMA stops sending data'' problems with this combination.

Perhaps we need to devise a test to see if we can detect data corruption in our image sensor data - perhaps it's happening now and we're just unaware of it.

Thank you again for your help - this is really great information.