Errata Item 2.12

[andya]

Posted on March 31, 2009 at 16:04

Errata Item 2.12

[16-32micros]

Posted on May 17, 2011 at 13:07

Hi AndyA,

Could you please describe your application usage of DMA and FSMC within STM32 High density devices, The solutions or workarounds depend on the application it self( Mainly, the numbers of transfers in buses and sharing between CPU and DMA and of course their occurrence in time ) to the System-Bus. It is true, that in some cases, it would be quite very complex to find a suitable solution like if in applications where the main code is executing out of the FSMC (NOR Flash) and DMA is enabled to access the FSMC banks areas.. Hope this answer a small part of your question, Cheers, STOne-32.

[andya]

Posted on May 17, 2011 at 13:07

Hi All,

What does this errata item actually mean? To me this sounds like you cannot use DMA period. I do not see how one can 'workaround' the issue by guaranteeing that DMA will not be active whilst the CPU is accessing the FSMC. Can anyone shed any light on what this is really all about? Has anyone actually worked around the problem in a satisfactory manner, i.e. one where DMA can still be used in a meaningful manner? TIA Andy

[andya]

Posted on May 17, 2011 at 13:07

Hi,

Yes, sure. In my application we have off-chip flash and off-chip RAM. The flash holds data only, no code, and contains audio and bitmap data for use at our product's UI. To display a screen the graphics engine will pull-in the approproate bitmaps to skin the controls as necessary. To play audio, the STM32 DAC shall be setup to DMA data from the external flash into the STM32 and out to an audio amp and speaker. The off-chip RAM is to hold a display framebuffer for access by the grpahics engine - this will be a frequently accessed device. The intention is to store and execute all code from the on-chip flash. So, at present, the only use of DMA is to pull-in the audio data from external flash, but this may not be the sole use in the final product (that depends on the gravity of this bug). If push-came-to-shove then we could try and store the audio data in on-chip flash to reduce the DMA vs FSMC acccess issue that this bug is talking about. Is that enough of a background? I have not included sizes of audio data, duration of audio, etc because that is probably irrelevant to the nuts and bolts of the problem - sequencing and control of DMA with FSMC access. I am very keen to hear more back on this issue as it may mean that we do not use STM32 and in fact go with a different Cortex device. However, I have a lot of faith in ST and their products and so would love to stick with the STM32. Regards Andy

[rs11]

Posted on May 17, 2011 at 13:07

Hi,

I am also planning to use STM32 in a very similar application, where I need to DMA in data from the external Flash on FSMC and then DMA out the data to a memory mapped peripheral on the FSMC. I hope to be able to synchronize these two operations, since the use cases are synchronous. IMHO, you may need to create some form of a mutual exclusion for read and/or write operation using the DMA to workaround this errata.