DMA2 Not getting interrupt

[ch2]

Posted on February 24, 2014 at 16:42The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on February 25, 2014 at 01:55

Well it needs to find it's way to DMA2_Stream1_IRQHandler(), or whatever you have in the vector table.

[ch2]

Posted on February 25, 2014 at 05:39

Thaks Clive for the answer. Well here is the caller function

void DMA2_Stream1_IRQHandler(void){ /* Process All DMA2_Stream1 Interrupt Sources */ DCMI_DMA_ProcessIRQSrc();}why it is not getting its path to its vector I could not figure out where configurations are going wrong. 

[Tesla DeLorean]

Posted on February 25, 2014 at 15:30

If DMA activity isn't occurring, the interrupts will also not occur. Check the source of the data.

[ch2]

Posted on February 27, 2014 at 05:44

Hi,

The interrupts are working now. The DMA2 is working in Ping-Pong fashion. Now I have an issue with DMA2. When I get half/Full transfer interrupt I write the data to SDIO which is again using DMA2. Whats happening now is that the blocks in SD/MMC are skipped. Core and Internal busses is working at full speed. I cannot figure out where the problem lies. Here is the code snippest.

void DCMI_DMA_ProcessIRQSrc(void)
{
/* Test on DMA channel 1 Transfer Complete interrupt */
if (DMA_GetITStatus(DMA2_Stream1, DMA_IT_TCIF1))
{
DMA_ClearITPendingBit(DMA2_Stream1, DMA_IT_TCIF1);
//USART_SendData_s(USART3,''DMA CH1 Full Transfer

'');
memcpy (DCMI_Buffer_2, DCMI_Buffer_1 + 512, 512); // upper half
SD_WriteBlock(DCMI_Buffer_2, Ptr_Addr_Img_start, DMA_DCMI_FIFO_BUF_Size);
Ptr_Addr_Img_start += 512;
//SD_WaitWriteOperation();
}
/* Test on DMA channel 1 Half Transfer interrupt */
if (DMA_GetITStatus(DMA2_Stream1, DMA_IT_HTIF1))
{
DMA_ClearITPendingBit(DMA2_Stream1, DMA_IT_HTIF1);
//USART_SendData_s( USART3,''DMA ch 1 Half Transfer 

'');
memcpy (DCMI_Buffer_2, DCMI_Buffer_1 , 512); // lower half
SD_WriteBlock(DCMI_Buffer_2, Ptr_Addr_Img_start, DMA_DCMI_FIFO_BUF_Size);
Ptr_Addr_Img_start += 512;
//SD_WaitWriteOperation();
}
if (DMA_GetITStatus(DMA2_Stream1, DMA_IT_TEIF1))
{
DMA_ClearITPendingBit(DMA2_Stream1, DMA_IT_TEIF1);
USART_SendData_s( USART3,''DMA ch 1 Transfer Error

''); 
}
}

Also when I enable function

SD_WaitWriteOperation();

mircontroller stalls.

[francescatodiego]

Posted on February 27, 2014 at 09:33

for fast card write put the card in receiver state with CMD25

check status with CMD13 when cars reply confirm the receiver state start write the write mode is always active you must only start data transfer without send any command before. Terminate data transfer with CMD12 stop transmission With CMD13 read status and wait until card return in transfer state

[Tesla DeLorean]

Posted on February 27, 2014 at 19:13

Some how I think this seriously underestimates the complexity of writing to the card, and that writing under interrupt probably isn't going to work very well, and writing a single 512 byte block is about the most inefficient operation possible. Are the data rates close to matching? Is

DMA_DCMI_FIFO_BUF_Size

512 bytes?

[ch2]

Posted on February 27, 2014 at 19:29

well, Clive what do you suggest? By using polling HT/FT (DMA2) bits or disabling DCMI at the start of interrupt and enable it while exiting. By disabling and enabling at the start and the end of interrupt I was able to write each and evry block but I haven't checked the frame data hope to check it tomorow. 

Also I haven't checked the enabling and disabling of streams. It is a bit diffcult as I just moved from PIC32 devices to STM devices. Also there are very few examples and I think the documentation is a bit messy. 

[Tesla DeLorean]

Posted on February 27, 2014 at 21:35

Well I'd start by having a very clear idea what my inflow/outflow rates are. I probably wouldn't double buffer, unless I was planning on providing a list of buffers. I would defer the SDIO writing to a different task, and write enough data for it to occur efficiently. I wouldn't copy data unless there was some compelling reason too.

[francescatodiego]

Posted on February 28, 2014 at 08:08

The default driver that comes with the library ST performs the whole write command sequence at each call and penalizes the maximum write speed of the SD.

If you also check the write end with SD_WaitWriteOperation the delay is even greater because the procedure return only when all the transfer is complete and the SD card is in trans state (and next time you must put it in recv state before write next block) For maximum transfer rate you have to put the SD card in recv state before start read DCMI and only trigger SDIO DMA transfer when you have a block of 512 bytes ready I have no experience with the DCMI but since the DCMI and SDIO both share the same DMA I would try to use a higher priority for DMA DCMI than dell'SDIO although this might give you problems underrun of the transfer to the SDIO In this blog where you can find a lot of informations http://blog.frankvh.com/2011/08/19/stm32f2xx-digital-camera-interface-dcmi/ http://blog.frankvh.com/2011/08/18/stm32f2xx-dma-controllers/