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.

[ch2]

Posted on February 28, 2014 at 12:43

Thanks Francescato Diego and Clive1 for the suggestions,

@ Francescato Diego you wrote ''

only trigger SDIO DMA transfer when you have a block of 512 bytes ready

''. Did you mean that data should only be tranfer data by only this function ''SD_LowLevel_DMA_TxConfig(uint32_t *BufferSRC, uint32_t BufferSize)'' and then disabling the SDIO stream. or should I just use following functions and then disable streamDMA_FlowControllerConfig(SD_SDIO_DMA_STREAM,DMA_FlowCtrl_Peripheral);/* DMA2 SDIO stream enable */DMA_Cmd(SD_SDIO_DMA_STREAM, ENABLE);Thanks in advance...

[francescatodiego]

Posted on February 28, 2014 at 15:26

I wrote

my

SDIO

driver

(

is

a first version

and

I have some problems

, but it works)

I don't

use

the ST library

with SD card is in recv mode I write

consecutive

blocks of 512bytes with this code

case SD_OP_WRITEBLOCK038:
 

SDIO_DMACmd (ENABLE); // I think is in a wrong position and this cause a DMA fifo error at transfer start (I read a recently appnote from ST)

SD_DMA_config (sd.data.ptr, (sd.data.blocks * SD_BLOCK_SIZE), DMA_DIR_MemoryToPeripheral) ;
SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;
SDIO_DataInitStructure.SDIO_DataLength = (uint32_t) (sd.data.blocks * SD_BLOCK_SIZE);
SDIO_DataInitStructure.SDIO_DataBlockSize = (uint32_t) SD_BLOCK_SIZE_2POWER;
SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToCard;
SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;
SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;
SDIO_DataConfig(&SDIO_DataInitStructure);
sd.opstate = SD_OP_WRITEBLOCK045;
case SD_OP_WRITEBLOCK045:
if (sd.DMAtransfer) break ;
 if (!(SDIO->STA & SDIO_FLAG_DATAEND)) break ;
 if (SDIO->STA & SDIO_FLAG_TXACT) break ;
 SD_disable_data_path () ;

My SD_DMA_config is similar to SD_LowLevel_DMA_Tx config DMA for data transfer after this call I see with emulator the DMA stream fifo is loaded with first 4 dword data and wait the SDIO data path enable before write to SDIO fifo (Frank blog explain very well the transfer mechanism) The sd.DMAtransfer is a flag set to 1 (in SD_DMA_config) while DMA transfer in progress and reset in DMA interrupt procedure when trasfer is complete Note that the DMA fill SDIO fifo and when DMA transfer is complete the SDIO transmission is still in progress Before disable data path you must wait SDIO end of transmission. In this driver release I have added two bit test but this check is work in progress.

I also tried the solution that you suggest with the fewest number of possible configurations for DMA but did not work for me and I have not investigated

static void SD_DMA_enable (uint32_t p, uint32_t len, bool dir)
{
sd.DMAerror = 0 ;
sd.DMAtransfer = 1 ;
DMA_Cmd (SD_DMA_STREAM, DISABLE);

 

DMA_MemoryTargetConfig (SD_DMA_STREAM, p, DMA_Memory_0) ;
DMA_SetCurrDataCounter (SD_DMA_STREAM, len/4) ;
DMA_SelectDirection (SD_DMA_STREAM, dir) ;

 

DMA_StreamEventFlagClear (SD_DMA_STREAM, DMA_IT_FLAGS) ;
DMA_Cmd (SD_DMA_STREAM, ENABLE);
}

[ch2]

Posted on March 01, 2014 at 06:17

Thanks Francescato Diego for the code example. Can you put your SDIO driver here, It may be helpful to alots of people working with SDIO.

[francescatodiego]

Posted on March 02, 2014 at 12:59

uhm ...

my boss

fire me

... he

pays me

for

the firmware development. 

The driver is not difficult to create require only few days starting from zero (like me)

With Google

you can find

several

examples .

ask me

all you need

and

I'll help you

(

with

my bad english

...

)

In my opinion

for this application

you just have to

break the

SD

write

procedure from ST library

into three

procedures

:

The

first 

called

before start acquiring

form

DCMI 

puts

the SDcard

in

recv

mode (ST library SD_WriteMultiBlocks

but without the last call   SDIO_DataConfig )

The second

that

triggers

the

DMA

after rx

512 bytes block

, (New procedure with DMA config and call to SDIO_DataConfig) T

he third that

sends

the

stop command to card after

acquisition

completed

(ST library SD_StopTransfer())

[ch2]

Posted on March 03, 2014 at 08:07

No issue, in your last post what does this function mean

SD_disable_data_path () ; 

does it mean disabling the straem or DMA or both?I set the sd card to receive mode and I found some success (thanks for the suggestion)...

[francescatodiego]

Posted on March 03, 2014 at 12:05

static void SD_disable_data_path ()
{
SDIO->DCTRL &= ~SDIO_DPSM_Enable ;
}

DMA stop is automatic mode after block transfer

[ch2]

Posted on March 07, 2014 at 10:38

@Francescato I have putted the SD card in receive (multiple block) mode but it still seems to be writing a few blocks. I have also tried the SDIO with polling mode but the problem still remains the same (few blocks written).

@Clive1 Here are some of the parameters of my dataPixel clock = 27MHzHsync = 15.6KHzCamera Ressolution = 720*480 (25 fps)Pixel Format YCbCr 4:2:2SDIO clock 24MHzSDIO class = 4

[Tesla DeLorean]

Posted on March 07, 2014 at 16:17

Ok, but that really doesn't suggest you've worked through the math here.

What is the WRITE bandwidth of you SD/SDHC card? Can you demonstrate that OUTSIDE of your streaming from the camera concept. Test your code and understand it's functionality and performance, and do this independently of anything else using data patterns you control and understand. Verify that it writes properly, and quantify how quickly it does so. Somehow the card spec would suggest a write speed below 6 MBps, and perhaps as bad as 2 MBps. You video spec suggests you're generating frame data in the order of about 9 MBps, and arguably getting bursts in the order of 27 MBps How do you plan on handling these disparities?

[francescatodiego]

Posted on March 07, 2014 at 17:23

Follow the Clive suggestions

 

I

just add

some

technical info:

You must

read

the

card

CSD

register

during the

driver init procedure This register contain info about the 

maximum write speed for card.

With this info you can

configure

the SDIO clock PLL

and y

ou must

use

class 10

devices

for

high-speed

write

Before start write

new data block check for driver errors

and first query the state of the card with

CMD13

The CMD13 reply contain the card status if card busy you must wait previous write end before write next block (card status recv)

(

SD

specs.

explain in detail

the change of state

when accessing

the SD card

...

I

can't explain it

clearly

with my bad english)

[francescatodiego]

Posted on March 08, 2014 at 08:47

thought night ...

Frank in his blog

http://blog.frankvh.com/2011/12/30/stm32f2xx-stm32f4xx-sdio-interface-part-2/ answers a question as

Very useful , Explained in great detail .

Thanks a lot!

Out of curiosity : Did you try to operate the SD interface at 25MHz than blackberries ?

48MHz Should Be possible?

What was the best write speed Could you manage ?

Frank 's answer

I've personally not run faster than 20 MHz , two to the repute my hardware Has a level converter ( 1.8V - 3.3V ) between the STM32 and the SD Card Given That, the fastest write speed 've Has Been Achieved

9 MB / s Which actually is not too bad (I'll admit it , I was happy ) .

I've no doubt faster speeds are possible , but you'd certainly need to run the STM32 at 3.3V so you can avoid a level converter to make SD Card Those faster clock speeds possible.

I think if you

write

a driver

SD

taking care of the

details and

using the right

SD card

you should

get this

result.

But you have a problem because your DCMI and SDIO peripherals share the same DMA .

I never used the DCMI peripheral but

I have read

the datasheet

:

If you transfer

8 bits / pixel

at 27MHz

I read

that

DCMI

trigger

an interrupt when

a

dword

is ready

then

the

DMA

interrupt

frequency

is

around

7MHz

(

...

right

?

)

I've read that DCMI can exec hw JPEG compression does not know how it works and how it change the the bit rate, but you could try ( if you do not already ) An alternative (also in this case to be studied the transfer time) would be connect an NAND flash on the FSMC bus (which device you uses ? ) The peripheral do ECC in hardware and you will have deal ''only'' with wear leveling

In this way the

DCMI

could transfer

in

DMA

directly

in the flash memory

.