2013-09-20 08:30 AM
Hello,
I am using a STM32F407. My application needs both USART1 and USART6 to concurrently receive data. I would like to use DMA2 to transfer data received from each USART to external RAM via the FSMC and ensure no data is lost. In the Errata document for this device (Section 2.1.10 of DM00037591) it says that DMA2 may corrupt data with certain peripherals when they are used concurrently. Does anyone know if this errata applies to DMA2 when USART1 and USART6 are used? #stm32f2-usart1/6-dma2 #usart-dma22013-09-20 03:16 PM
According to DMA2 errata the USARTs are okay as long as you don't use DCMI and crypto/hash DMA. What the errata doesn't say is that DMA2 may still act erratically unless you use FIFO mode. I was not able to get USART1 working reliably with DMA until I configured the FIFO and burst mode. The symptom is spurious interrupt requests on the USART channel while DMA is running.
Jack Peacock2013-10-03 06:55 AM
Any idea if there are issues with USART1/6 and DMA2 when transmitting?
I ask because I have a problem at the moment where all the setup _looks_ OK, I can send one string, but subsequent strings never send and NDTR does not decrement. I have a post with more detail here:https://rowley.zendesk.com/entries/27125403-STM32F2-USART1-6-DMA-sends-one-string-only
2013-10-03 08:22 AM
The whole stream/flags decoding seems bogus
case (uint32_t)USART1: flags = DMA_IT_FEIF1|DMA_IT_HTIF1|DMA_IT_TCIF1|DMA_IT_TEIF1; break; Isn't this DMA2 Stream 7? Where did 1 get plucked from? USART2_TX and UART5_TX also appear wrongly associated.2013-10-03 09:10 AM
Ah; Indeed; Certainly is.
Confusion between usarts and DMA streams. And that does seem to have fixed it. Thinking about this, I suspect I built that code from an example from the peripherals lib that used USART3 and as it happens, USART3 is on Stream3. My guess is that I made a rash presumption some time back that hadn't until now bitten me. Thanks Clive. A star as usual! Gordon.