Old DMA2 bug found in new MPU STM32F427 ?

[zbynek]

Posted on March 04, 2014 at 13:59

Hello,

We use

STM32Fxx MPU

in many projects

. During the development

of new equipment with STM32F427

, we

have run into this

problem:

We use

SPI

4, which

is controlled by the

DMA

. Streamer DMA2_Stream1 is used for sending, DMA2_Stream0 for reading. DMA2_Stream0 generates an interrupt, which

processes the

data

and restarts

transmission

(for many

reasons it is not

possible to use

cyclic DMA

)

.

Interrupt handler looks like this

(actually the last

version

, program

has been

completely

rewritten

,

unfortunately

behavior is the same

:(

void DMA2_Stream0_Irq (

)

{

    ...

   SPI_Cmd(SPI4, DISABLE); 

   SPI_DMACmd(SPI4, SPI_DMAReq_Rx | SPI_DMAReq_Tx, DISABLE);

   DMA_Cmd(DMA2_Stream0, DISABLE);

   DMA_Cmd(DMA2_Stream1, DISABLE); 

   while (DMA_GetCmdStatus(DMA2_Stream0)!=DISABLE) {}; 

   while (DMA_GetCmdStatus(DMA2_Stream1)!=DISABLE) {}; 

   DMA_SetCurrDataCounter(DMA2_Stream0, 14);

   DMA_SetCurrDataCounter(DMA2_Stream1, 14);

   DMA_MemoryTargetConfig(DMA2_Stream0, MemRx, DMA_Memory_0);

   DMA_MemoryTargetConfig(DMA2_Stream1, MemTx, DMA_Memory_0);

   DMA_Cmd(DMA2_Stream0, ENABLE);

   DMA_Cmd(DMA2_Stream1, ENABLE);

   SPI_DMACmd(SPI4, SPI_DMAReq_Rx | SPI_DMAReq_Tx, ENABLE);

   SPI_Cmd(SPI4, ENABLE);  

}

Up to this point

everything is

ok

.

T

he transmission

works perfectly,

a

ll tests

of reliability and

performance

went well.

Then we

implemented a

simple

DMA

transfer

memory2memory (for the purposes of

TCP

stack). We used

DMA2_Stream7.

Separately,

both

communication works

perfectly

. If

, however, are

used simultaneously

,

errors occur

.

DMA2_Stream0 interrupt is not called

.

It looks as

if the

SPI4

read

by one character

less

than

sent

.

After error, DMA2_Stream0 is enabled (and

waits

indefinitely

), has

NDTR=1 and

TCIF

=0

.

 DMA2_Stream1 is stopped, has

NDTR=0 and

TCIF=1.

From these data

it is evident

why

SPI

stops working

.

I remembered

that a similar

errata was

in the chip

STM32F407. And indeed

,

error

occurs

only

if

source addr is FMC!!!

Shortly

, if dma memory2memory is:

            SRAM-

>

SRAM ... everything is

ok

            SRAM-

>FMC

... everything is

ok

FMC

-

>FMC

... error

FMC

-

>

SRAM ... error

Oddly enough

, this error

is not described in

the 

errata documentation.

It is

this error

and is there a

workaround

?

Or am I doing

something

wrong

?

[zbynek]

Posted on March 04, 2014 at 14:27

Yeah

,

I forgot to add

the following

:

    We tried

all possible configurations

DMA

(with and without

FIFO

, various

streamers

, etc.)

    We wrote

many variants of

the interrupt handler

(recently

published

,

in

fact,

is not good.

DMA

should be stopped

prior to

the disabling SP4 - but

it has no effect

).

[GHITH.Abdelhamid]

Posted on March 04, 2014 at 18:58

Hello, 

it's hard to help you and answer your questions with few details can you share:  - HCLK,PCLK2,SPI4_CK frequencies  - SPI_SR register value (when the fail is seen).  - DMA2_Stream7 CR register value and NDTR  - DMA2_Stream0 CR register value  - FMC BCR and BTR registers value. Br, Abdelhamid.

[zbynek]

Posted on March 04, 2014 at 22:09 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6eC&d=%2Fa%2F0X0000000bsP%2FHSDz3goPphP2Bk1eOdK0IXySS34zgj6xXfGy4FCoGTg&asPdf=false

[zbynek]

Posted on March 04, 2014 at 22:29

I forgot:

SP4->CR1 = 0x0364

SP4->CR2 = 0x0003

SP4->SR = 0x0042

[waclawek.jan]

Posted on March 05, 2014 at 08:46

Ahoj Zbyňku,

> SP4->SR = 0x0042 The SPI receiver overruns due to the DMA being busy with the FMC->xxx transfer for too long. Try transferring shorter chunks of data from FMC, or lower the SPI clock rate. If the timing is marginal, assigning the SPI-Rx DMA stream higher priority than the SPI-Tx DMA stream might help, but in a more complex setup I wouldn't rely on that and I would attempt to calculate (I admit there may be not enough information in the published documetnation for this) or establish experimentally the timing budget. JW

[zbynek]

Posted on March 05, 2014 at 14:55

Cześć

Honzo,

Thanks a lot

for your advice

, but

unfortunately

it did not help

.

I changed the

priority

of DMA Stream (RX=VeryHigh, TX=High, M2M=Low), slowed

SPI

, but

without any progress.

Today I received by mail an official statement from STM. The report does not indicate whether content can be published, so here is my

brief

transcript

:

1. They

   admitted that

   the problem may be in

   the chip

   . More specifically,

   in the

   FIFO,

   which

   is

   built into the

   FMC

   . Errata DMA2 was not fixed.

2. As a

   workaround

   they

   recommend to use DMA M2M triggered by timer.

<end of

transcript

>

Use this

DMA

seems to me

like a pretty good idea

.

I

'll try it

and let you know

.

Zbynek

[waclawek.jan]

Posted on March 05, 2014 at 18:10

>

I changed the

priority

of DMA Stream (RX=VeryHigh, TX=High, M2M=Low), slowed

SPI

, but

without any progress.

Yes, but your data/address setup times indicate that your FMC/SRAM read is set to really, really, incredibly sloooooooow...  15+255=270 cycles, that's 1.5us even at 180MHz clock. And the other DMA channels have to wait until the whole transfer is finished, so add a couple of cycles for the write to internal SRAM, and multiply that by the number of bytes you are trying to transfer... I'd say, you should try some benchmarking. > They

admitted that

the problem may be in

the chip

. More specifically,

in the

FIFO,

which

is

built into the

FMC

. I am not sure they understood your problem. There's no FIFO involved when you are *reading* from the SRAM controller of the FMC.

The timer-triggered DMA is a good idea, but for a different reason: as it involves only one transfer at a time, it allows to interleave other DMA streams (if they have higher priority); but bear in mind that still the DMA will wait at least for that one read (btw. the whole AHB bus where the FMC is sitting is blocked for that time, luckily, there's no other peripheral on that bus; so unless some other master e.g. the processor wants to access FMC it's not a big issue). It's that 1.5us, so, if your SPI is say 10MHz/8bit, i.e. one received frame per

0.8us

, and you are in trouble again. Is it really necessary to have such data/address setup times? Jano Waclawek (áno, to priezvisko je mätúce... :) )

[zbynek]

Posted on March 05, 2014 at 22:02

Cześć Jano,

Unbelievable

!

  T

he

problem

seems to be

solved!

After

I read

„that's 1.5us even“ everything

suddenly became clear

. Of course

you're right, 1.5us

is awfully

long time

. Now I

totally

understand what

was happening on the

AHB

bus

. Oh

yeah, it's embarrassing

.

That's

a real

chess

blindness

.

With 250ns bus cycle, everything is OK.

I had

in my head

that old

errata

and

I was too

focused

on it. I did not realize

that the

FMC cycle

takes so

long.

Meanwhile,

I have

implemented

and tested

the mentioned

M2M DMA, works well, but I'm not

decided

whether

to

use it.

Jano, I would

like

to

thank

you for

the

useful

advice

.

Y

ou helped me very much.

I do not know

how to

repay

you

.

With kind regards

Zbynek