Sign in

username:

password:



Not a member?

Search c55x



Search tips

Subscribe to c55x



c55x by Keywords

AIC23 | C5509 | CCS | CSL | EMIF | EVM | GEL | GPIO | HPI | Interfacing | JTAG | McBSP | OMAP | Omap15 | OMAP59 | RTDX | SDRAM | TMS320VC5509 | USB | XDS5

Discussion Groups

Discussion Groups | TMS320C55x | strange DMA behaviour

Technical discussions about the TI C55x DSPs (including the c5501, c5502, c5503, c5507, c5509, c5510 and OMAP5910).

  

Post a new Thread

strange DMA behaviour - Ulf - Mar 13 7:59:51 2007



Hi!

I=B4ve a very strange DMA behaviour.
I use a DMA to sent data from memory to the mcbsp transmit register=20
and another DMA to sent the received data from the mcbsp receive=20
register to memory. I use a circular buffer for the transmit register=20
as well as for the received data. The mcbsp uses the same frame sync=20
for receiving and transmitting and the transmit DMA uses the mcbsp=20
transmit event for synchronization and the receive DMA uses the mcbsp=20
receive event.
=20
Normally the answer on the first entry of the transmit circular=20
buffer is at the second entry of the receive circular buffer, the=20
second entry of the transmit circular buffer is at the 3rd entry of=20
the receive circular buffer and so on (behaviour 1). But sometimes=20
the answer on the 1st entry of the transmit circular buffer is at the=20
1st entry of the receive circular buffer, the 2nd entry of the=20
transmit circular buffer is at the 2nd entry of the receive circular=20
buffer and so on (behaviour 2). And sometimes the transformation=20
between transmit and receive circular buffer changes during program=20
flow (behaviour 3).
Has anyone an idea for the reason of this troublesome behaviour?

I found a workaround for my problem and this is the strangest thing.=20
I use an if instruction with a condition that is normally false. The=20
first instruciton of the if-body is a function call. If I uncomment=20
the function call or if I insert some dummy instruction before the=20
function call my DMA works well (behaviour 1).=20
But the function call has nothing to do with the DMA and I can notice=20
by a breakpoint that the function call isn t performed. How can this=20
instruction affect the DMA?

=20

=20


(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Re: strange DMA behaviour - Jeff Brower - Mar 13 13:26:08 2007

Ulf-

> I´ve a very strange DMA behaviour.
> I use a DMA to sent data from memory to the mcbsp transmit register
> and another DMA to sent the received data from the mcbsp receive
> register to memory. I use a circular buffer for the transmit register
> as well as for the received data. The mcbsp uses the same frame sync
> for receiving and transmitting and the transmit DMA uses the mcbsp
> transmit event for synchronization and the receive DMA uses the mcbsp
> receive event.
> 
> Normally the answer on the first entry of the transmit circular
> buffer is at the second entry of the receive circular buffer, the
> second entry of the transmit circular buffer is at the 3rd entry of
> the receive circular buffer and so on (behaviour 1). But sometimes
> the answer on the 1st entry of the transmit circular buffer is at the
> 1st entry of the receive circular buffer, the 2nd entry of the
> transmit circular buffer is at the 2nd entry of the receive circular
> buffer and so on (behaviour 2). And sometimes the transformation
> between transmit and receive circular buffer changes during program
> flow (behaviour 3).
> Has anyone an idea for the reason of this troublesome behaviour?
> 
> I found a workaround for my problem and this is the strangest thing.
> I use an if instruction with a condition that is normally false. The
> first instruciton of the if-body is a function call. If I uncomment
> the function call or if I insert some dummy instruction before the
> function call my DMA works well (behaviour 1).
> But the function call has nothing to do with the DMA and I can notice
> by a breakpoint that the function call isn t performed. How can this
> instruction affect the DMA?

If inserting "dummy code (or data)" has an effect, then the likely issue is
alignment.  For C55x some cases might be making a double-word access on odd boundary,
DMA-accessible array/buffer not on even boundary, etc.  When you insert the bogus
instruction, you might be getting correct alignment.

I suggest to study your .map file carefully for both cases, in particular a) the ISR
code for DMA events, and b) data being accessed by the DMA.  If these are not showing
in your .map file then use the -g option to make all symbols global.

-Jeff



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )