Warning: limit simultaneous DMAs to 2

infoinfo989 · ‎2012-01-13

Posted on January 14, 2012 at 01:53

We've been working on this problem with the F2x and F4x for some time, and figure it's about time to warn others about what we've found. You can find the full details here:

http://blog.frankvh.com/2012/01/13/stm32f2xx-stm32f4xx-dma-maximum-transactions/

but in short, you probably should limit the number of simultaneous DMA transfers to 2. We've seen problems with more than 2 active DMAs on both the STM32F2xx and F4xx parts. We've given a testcase to ST and they've confirmed seeing this problem - hopefully they can shed some more light on what's going on.

infoinfo989 · ‎2012-01-23

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.

Danish1 · ‎2012-02-18

Posted on February 18, 2012 at 13:46

Does anyone know when this important information will reach the errata sheets?

Might using the DMA in Direct mode make any difference to the problem?

(My posting is really to keep this important information high up the forum list until it reaches the errata.

The ST website points to:

Revision 2 of DM00037591.pdf 12-Dec-2011 which is Doc ID 022183 Rev 2, STM32F40x and STM32F41x Errata sheet

Revision 2 of DM00027213.pdf 20-Dec-2011 which is Doc ID 018757 Rev 2, STM32F20x and STM32F21x Errata sheet)

- Danish

Gawie · ‎2012-02-25

Posted on February 25, 2012 at 11:08

Hi ST1,

I am really interested in your answers to Frank's last questions - but seems like you have missed it ;-).

Please provide us with some answers.

Thanks,

Gawie

sacleary · ‎2012-08-04

Posted on August 04, 2012 at 14:11

Frank -

Thank you very much for your blog. We are currently developing a system for the STM32F417 using ADC, SPI, SHA1 and SD, and your blog has been helpful in many areas!

ST -

Our system is very data-intensive, collecting ~1TB of data at a very fast rate. So we need to use DMA at least for parts of it.

In addition, any failure to capture the data during operation would cause us a loss of hundreds of thousands of dollars. So get your act together and issue a complete, accurate errata - or we're switching to Atmel.

Thank you,

-Steve

waclawek.jan · ‎2012-08-13

Posted on August 13, 2012 at 13:33

There's a new Errata at least for STM32F4xx (Rev.3) available, and as far as I can tell it deals with this problem (chapter 2.1.9).

JW

jj2 · ‎2012-08-13

Posted on August 13, 2012 at 14:52

Doubtful - such threat has any impact. (and - has very hollow ''ring'' - Atmel, capable & errata-free - really?) Unless your firm is ''lead,'' key, or can convincingly assert 100K EAU - loss of your biz, ''in the noise.''

Suggest instead: reporting ongoing loss of time, effort, productivity - providing far more compelling reasons as to just why this particular ''fix'' should rise on maker's to-do list...

sacleary · ‎2012-08-23

Posted on August 23, 2012 at 19:36

As noted in this thread, ST released the updated errata in early August. But they had a reproducible test case at the beginning of November. So it took them 9 months, and during that time we chose ST over Atmel (the first time a non-Atmel chip has been chosen in our company).

Regarding Atmel, their chips are certainly not error-free, but I believe their documentation (both errata and datasheet/reference) is far, far superior to ST. ST has related documentation spread over several different ST and ARM docs, while Atmel brings it all together.

I actually don't care if ST fixes this problem in the next revision - I just wanted it documented so we can at least work around it and know our approach will work.