Skip to main content
subscriptions
subscriptions
Associate III
July 9, 2014
Question

DMA2 problems: NDTR not zero

  • July 9, 2014
  • 8 replies
  • 1602 views
Posted on July 09, 2014 at 18:40

I'm having some problems with DMA transfers apparently stalling on our STM32F405ZGT6 board.

The problem seems to only happen when I have multiple streams running.

So, I have Stream3 using SDIO, with 32 bit wide access,

and I am also driving an SPI peripheral using Stream 5 (mem to periph) and Stream 0.

The problem I seeing is that occasionally either stream 5 or Stream 3 will fail to complete the transfer, leaving a non-zero value in NDTR.

Any suggestions on what to look for when trying to figure this out?

#stm32 #dma
This topic has been closed for replies.

8 replies

waclawek.jan
waclawek.jan
Super User
July 10, 2014
Posted on July 10, 2014 at 13:20

Do you use FIFO/memory bursts?

Is the value left in NDTR random?

What is the value of respective flags in LISR/HISR at that moment?

JW

subscriptions
subscriptionsAuthor
Associate III
July 11, 2014
Posted on July 11, 2014 at 08:15

I'm using direct mode, so the fifo should not come into play.

I wouldn't say the value is random.  It is never more than the value I set.  Some of the transfer completes and then it stalls.  For instance, in one case I set it to 12 on the SPI channel, and I've seen values of 1 and 2 in the register.

I'm concurrently running a 1KB transfer to the SDIO.  I have also seen that transfer stick.

The destination memories may cross 1KB boundaries.  Does that make any difference?

As far as I know the code isn't setting any values for new addresses or changing anything on the stream until the previous transfer has completed. 

I don't have access to the device until Monday, so can't tell you what's in the other registers, but I will go study the documentation on them to see what I could be looking for.

Thanks

subscriptions
subscriptionsAuthor
Associate III
July 11, 2014
Posted on July 11, 2014 at 18:51

OK, having read those, I'm confused by the inconsistency.

On the one hand, the errata says not to use both  AHB and APB2

On the other hand, the blog entry says, that someone else is seeing the problem with 3 AHB peripherals.

Is there any definitive statement that the latter is true, which is what I'm seeing.

If so, I could build a queue of DMA transactions, so only one would execute at a time

Of course, I'll lose throughput, and if that's not the problem waste time on a different implementation.

subscriptions
subscriptionsAuthor
Associate III
July 14, 2014
Posted on July 14, 2014 at 15:52

Currently, I'm seeing TEIF5 interrupts, and status.

What could be causing this?

subscriptions
subscriptionsAuthor
Associate III
July 14, 2014
Posted on July 14, 2014 at 23:06

It's looking like I've accidentally begun a new transaction on the DMA before the previous one has completed, and am therefore writing to some of the registers of the stream, due to a faulty state machine in my code.

waclawek.jan
waclawek.jan
Super User
July 15, 2014
Posted on July 15, 2014 at 10:58

A false alarm, then? :)

JW
subscriptions
subscriptionsAuthor
Associate III
July 15, 2014
Posted on July 15, 2014 at 16:34

Yes, it was all my fault.

State machine advanced from an incorrect place, and the next dma transfer was set up before the next one.

Still, maybe someone else who sees a transfer stop will find this, and see it was their fault too.  Thanks for everyone's help,.

Terms & ConditionsAccessibility statement