DMA + DMA interrupts kills system

[jonathan2]

Posted on October 06, 2008 at 20:26

DMA + DMA interrupts kills system

[jonathan2]

Posted on May 17, 2011 at 09:56

Hi.

I have an application which reads data from an external memory interface ADC which is generating 16-bit samples at 4MSPS. This is being put into 2 DMA buffers each holding 288 samples. The DMA is set up to automatically switch between the buffers using the LLI process. External memory accesses take 5 cycles to meet timing constraints (I could cut it down to 4 but it would be marginal so I'm reluctant). A timer generates a 4MHz pulse to the ADC which takes less than 225ns to do a conversion, and the falling edge of the (inverted) BUSY signal triggers an external DMA request. Both the src and destination are set to 16-bits, and the DMA is transferred To maximise throughput I have the CPU operating out of SRAM as DTCM, and the DMA naturally goes through the AHB. I have set up the linker to provide AHB (non-buffered) equivalent SRAM memory addresses for the buffers and link structures which are defined in the DTCM memory space - this all looks (and works) good. The DMA & EMI work fine unless I enable DMA interrupts in VIC0 (FIQ or IRQ - it doesn't matter). When DMA interrupts are enabled the system behaves very strangely/erratically (like other interrupts are being generated and/or data is being corrupted) and eventually gets a data abort exception with arbitrary address in lr (ie the data abort is being caused by the DMA). On investigation the DMA registers seem to have bizarre data resulting in inapproprate memory accesses and hence the data abort. I thought that it could be related to the relatively quick transfer rate (24 CPU clocks @ 96MHz) somehow interfering with the update of the linked registers (4 words), but slowing down the sample clock to below 1MSPS did not remedy the problem. I have tried enabling/disabling SRAM wait states but it appears to make no difference. The SRAM_LK_EN bit in SCU_SCR0 (which is poorly documented) has no effect. If I flood the system with UART0 interrupts (every 138us - cf DMA interrutps every 72us when enabled), the system behaves happily. Any thoughts on a work around would be appreciated. My next plan of attack is to disable DMA interrupts in the VIC and call the isr (out of interrupt context) when the DMA_TCISR shows that the terminal count is complete. thanks Jonathan Pratt

[jcrobb]

Posted on August 24, 2011 at 23:41

Hi Jonathan,

I cannot help you but perhaps you can help me ! I need to be able the read a 16bit wide par. output from my external 16bit a/d converter into internal 32F2xx memory. I have par. port C on the controller available and could generate the DMA int/event from the EOC of the external A/D but I do not see how to set up an external line as a DMA even trigger ???? I see how to otherwise configure the rest of  the DMA but not an external event trigger, is it possible ?  can you outline how this is done ? I also posted this to tech support, thanks

[Tesla DeLorean]

Posted on August 27, 2011 at 15:36

Rather than posting against a 3 year old thread for the STR9xx chip, try posting your question in the STM32 forum.

The forum has been ported and broken several times since this thread was created. You might want to see if there is a way to configure one of the timers to respond to an external signal, and in turn generate a DMA transaction.

[Pantuca.Erwin]

Posted on August 31, 2011 at 07:02

i only read the str9 topics currently since that is what we are still using now and dont have much time to browse topics. does that mean most str9 related info are being posted in stm32?

[Tesla DeLorean]

Posted on September 06, 2011 at 04:56

does that mean most str9 related info are being posted in stm32?

No, it means that people asking question about STM32 parts should be asking  about them on new/current threads in the STM32 forum not the STR9 one. John wrote ''I need to be able the read a 16bit wide par. output from my external 16bit a/d converter into internal 32F2xx memory''