AnsweredAssumed Answered


Question asked by Lordmonkey on Mar 4, 2015
Latest reply on Mar 19, 2015 by Lordmonkey



I'm having a difficult time with the BF536 DMA. I currently have a VDK based VoIP-like application which streams RTP out of the EMAC at 1 packet per 10ms. So it's 92 byte UDP plus the ethernet overhead.


In a 30-second streaming test I notice choppy audio at the far end. Inspecting Wireshark shows the stream drops ~5 packets. Looking at the core registers under VisualDSP++ I can see that there were exactly that number of underruns (EMAX_TX_DMAUND value). Repeating the test consistently shows these two values match, meaning that the dropped packets are being lost during DMA transfer to the EMAC.


The only higher priority DMA channel in use is EMAC Receive (DMA 1) and no packets are being receiving during the test, so this channel shouldn't be doing anything.There are other lower-priority channels used (SPORT0RX, SPORT0TX, UART0RX, UART0TX) but my understanding is that these would be pre-empted by the EMAC TX at priority 2. Is this assessment correct?


I have been working through some things to try to eliminate the problem. One idea was to move any data buffers in use to L1 memory. All buffers within my emac driver are already in L1, and application buffers and variable (such as sockets) have been moved in to L1 since. This does not seem to make an improvement.


I also tried to enable DMA Traffic setting DMA_TC_PER to 0x3800 but this actually makes it worse!


I also tried switching off the UART code so only the SPORT and EMAC were used. No change.


The only thing that seemed to make a difference in my application was when I altered the way in which the threads worked. This included varying the size of VDK_Sleep() within some loops, exchanging VDK_Sleep for VDK_Yield() on others where the only purpose of VDK_SLeep was to yield priority. However, this appeared to make the problem almost dissapear in some cases but in others make it even worse. Furthermore the same alterations removed and then put back would yield differing effects between code rebuilds, which is even more perplexing.


So if it is related to threading, or the VDK kernel, what should I consider that might affect DMA?