2.1.10 DMA2 data corruption when managing AHB and APB peripherals in a concurrent way

[stcom9174]

Posted on November 11, 2017 at 15:31

Hello,

I'm using the STM32F407VG in a project; doing DMA to/from memory from GPIOD using TIM1_CH1; and I'm seeing the DMA xfer get stuck - meaning; on RCV I only get the first byte; and on XMIT I only see the last byte; and I'm wondering if the reason could have something to do with this errata.

As far as my code goes; I've been following several of the examples and threads in this forum; and anything I can post at this point wouldn't really be any different or any help regarding the code (I think anyway).

Just wondering if any of you have had this issue; and could this erratum be the reason.

I'm using DMA2, Channel 6, Stream 1 and Stream 3.

Note I am transferring and receiving the correct # of bytes; but they are all the same; meaning; I just see a bunch of first bytes copied over on the receive; and on the transfer I just see a bunch of copies of the last byte being transferred as the xmit pkt.

I've seen similar questions as this - titled something to the effect of 'dma duplication' but not a single one of those threads has been answered; so, I hope this thread does get answered.

Thanks In Advance,

John W.

[stcom9174]

Posted on November 12, 2017 at 09:55

Tried this - but didn't do much other than xfer the same byte 12 times:

TIM_DMAConfig(TIM1, TIM_DMABase_CCR1 ,TIM_DMABurstLength_12Transfers);

[stcom9174]

Posted on November 12, 2017 at 10:09

I've been using this - and data transfers - but always the same byte:

TIM_DMACmd  (TIM1, TIM_DMA_CC1, ENABLE );  /* Enable TIM1_CC1 DMA Requests

TIM1_CH1

Data xfers across the interface - I can transmit and receive OK - but only one byte.

I did see some issues when I wasn't shutting down the XMIT stream in time to RCV - since the same timer channel is used for XMIT and RCV via the same GPIO port; it's easy to fool yourself into thinking something works when in fact you have a loop back.  Big clue for me was xferring and rcving bytes - lower nibble was OK; but upper nibble was corrupted - XMIT was putting data on the bus before the READ was done.  

But, this is an interesting way to do DMA - when I get the increment fixed - I'll have something that works.

Even just copying over the next byte in the stream one byte at a time would work now if I could get that next byte in the stream.

TIA,

John W.

[stcom9174]

Posted on November 13, 2017 at 09:50

Hello All,

Actually, in this case, turns out to be the target device - it was asserting a control signal that was preventing the next byte in the DMA stream to be sent; so the code works as advertised.

The hardest part in this, IMHO, make sure the clocking is ok and correct; check noise; any possible phase issues; and levels and check with good test equipment; and make sure you have your timer channels selected correctly and that you don't keep driving one stream while the other one is starting or shutting down.

In one of the ST DMA AN's, this is discussed briefly but should be made more of a major section in the AN since this happened when I was setting this up; and the results are obviously quite confusing when it does happen.

Regards,

John W.