Capture I2S using external framing on DM365 McBSP

WingEdLizard

I'm using a different codec that provides external i2s framing ( Different than the dm365 evm) . A sample is 64 bits: 32 on left, then 32 on the right channel.

However the transfer is not correct. The correct transfer params are 2x32 bits McBSP capture, then use the EDMA controller to strip off the correct bits. Here's what is supposed to be happening

|------ ONE Capture ----------------------------------------------------------------------|

|-- Left ------------------------------------|-- Right -----------------------------------|

<Byte_A> <Byte_B> <Byte_C> <Byte_W> <Byte_X> <Byte_D> <Byte_E> <Byte_F> <Byte_Y> <Byte_Z>

where The significant data is Left=ABC, Right=DEF.

Then the EDMA controller will pull off the data and stuff it into the following 16bit PCM format: ABDE

My capture does not produce correct data. Interesting, I can program the McBSP, to caputure 3x24bit words but the second channel is very low. This is because I am getting the following:

<Byte_A> <Byte_B> <ZERO> <Byte_D>: 'AB0D'

I'm able to adjust the gain so that the output is decent but there the resolution is poor on the second channel ( of course, only having 8 bits of data)

Here is the McBSP Regs:

SRGR.CLKSM = 0;

PCR.SCLKME =1

SRGR.FSGM = 1

PCR.CLKRP =1

PCR.FSRP = 1

SPCR.RRST = 0

SPCR.RINTM = 3

SPCR.FREE = 1;

RCR.RFRLEN=1; // 2 data words

RCR.RDATDLY=1; // 1 bit i2s data delay

SRGR.FWID=31; // 32 bit data word

SRGR.FWID = 63; // 64 bit left+right frame ( this is a don't care, since we are using FSR framing, i believe)

RCR.RWDLEN1 = 5; // 32 bit data word ( The define for this is wrong, 5 is 28bits for McASP, but on DM365 5 is 32 bits for McBSP)

dma_params->data_type = 2 ; // feeds into the EDMA DST_BIDX

Given that I have something working with 3x24 bits, but not 2x32 bits, it's got to be a data transforming issue. Understand that the

codec is providing the FSR framing signal and is sending a 32bit left and then 32bit right channel.

Questions:

1. Do the McBSP regs look ok?

2. Is the EDMA messing the data up?

a. How do I program the EDMA to send just block move the data? Here are the EDMA regs for my xfer ( captured in plat-davinci/dma.c):

OPT=0010_3000, A_B_CNT=1000_0004, BIDX=0002_0000 ( Why is SRCBIDX equal to zero).

3. Do you have any suggestions?

I'm using the Montavista kernel ( based on 2.6.18).

Thanks, Brett

over 15 years ago

0 WingEdLizard over 15 years ago

Intellectual 605 points

I have my diagram wrong: here is the correct diagram

|------ ONE Capture ----------------------------------------------------|

|-- Left ---------------------------|-- Right --------------------------|

<Byte_A> <Byte_B> <Byte_C> <Byte_X> <Byte_D> <Byte_E> <Byte_F> <Byte_Y>

There are 4 bytes per sample coming off the I2S, 24bits are significant, but we want to capture 16 bit PCM:

64bit I2S 16bit PCM

[ABCX.DEFY]xN --(edma)--> [AB.DE]xN

McBSP should be pulling off the 32bit samples :

RCR.FWID = 31 (32bits),
RCR.FPER=63 (64bits, don't care ( due to external framing)? )
RCR.RWDLEN1 = 5; // 32 bit data word ( The define for this is wrong, 5 is 28bits for McASP, but on DM365 5 is 32 bits for McBSP)

External Framing:

SRGR.CLKSM = 0; PCR.SCLKME =1.

EDMA Params:

OPT = 0x00103000
SRC = 0x01d02000
A_B_CNT = 0x08000004
DST = 0x8c226000
SRC_DST_BIDX = 0x00040000 ( Why is src_bidx zero?)
LINK_BCNTRLD = 0x00004820
SRC_DST_CIDX = 0x00000000
CCNT = 0x00000001

Same Questions:

McBSP programming correct?

EDMA programming correct?

Suggestions?

0 WingEdLizard over 15 years ago in reply to WingEdLizard

Intellectual 605 points

Additional Information:

Section 3.4 'Peripheral Servicing Example' in EDMA document (SPRUFI0) is relevent.

SRC_BIDX is zero, because the data is being pulled from the McBSP's DRR register @ 0x1d02000+0.

0 Craig Smith over 15 years ago in reply to WingEdLizard

Intellectual 810 points

Hi Brett, I am working on something similar so hopefully we can figure this out.

I am trying to pull off 32-bit audio samples from an external source (and keep the 32-bit samples). In your case, should you DST_BIDX be 2 instead of 4 if you are trying to go from 32-bit to 16-bit?

The problem I am having is that when I put the mcbsp in "slave" mode, I don't get any samples even though I know the external clock and framing are there (verified with scope). Anyway, I'm just getting started so I'll try to post again when I have more progress.

Regards,

-Craig

0 WingEdLizard over 15 years ago in reply to Craig Smith

Intellectual 605 points

I am capturing 4 bytes to 'look at the raw data'. I've hacked the wav file to make it 4 channels rather than two and I can see two perfectly good PCM streams and two really bad ones. I think that when I capture two it picks off the wrong two bytes ( the least sig bytes). Sort of an endian problem.

I am seeing data movement, so I don't think we are having the same problems. I'm using a different audio codec ( than the dm365 evm), what about you?

Brett

0 Craig Smith over 15 years ago in reply to WingEdLizard

Intellectual 810 points

I'm using the I2S output from an HDMI receiver. On the EVM, it was my understanding that the external codec (aic3101) was providing the clocks/framing so I figured the existing mcbsp/i2s driver code was already setting up the 365 in slave mode, but it doesn't look like it (based on looking at the code and adding a few print statements).

Like I said, I'm just getting started so I have not examined every bit of the mcbsp settings yet.

How are you capturing samples? I am using the following command:

arecord -t wav -d10 -r48000 -c2 -fS32_LE test.wav

0 WingEdLizard over 15 years ago in reply to Craig Smith

Intellectual 605 points

I'm using the same:

   [brettb@maven audtest]$ cat ch.rec
   arecord -f dat -t wav -d 8 $1.wav
   [brettb@maven audtest]$

To look at the data I'm using:

   [brettb@maven audtest]$ cat dwav32.sh
   od --skip=44 -t x4 --width=8 $1
   [brettb@maven audtest]$ cat dwav16.sh
   od --skip=44 -t x2 --width=4 $1
   [brettb@maven audtest]$
   [brettb@maven audtest]$ cat dwav8.sh
   od --skip=44 -t x1 --width=4 $1
   [brettb@maven audtest]$

and of course audacity to see the waveform.

0 Craig Smith over 15 years ago in reply to WingEdLizard

Intellectual 810 points

What I2S mode is your CODEC in? I just found that changing it makes a difference for me. Something is still not right, but it got better when I put it in "standard" I2S mode (it was in right-justified mode). I'll post a dump of what I'm getting a little later....

0 WingEdLizard over 15 years ago in reply to Craig Smith

Intellectual 605 points

I'm not using the a1c3x codec, but another one. I've tried i2s, and 16bit right justified modes.

see 'EDMA for byte order swapping ( endian, sort of)' if you are interested.

0 qiu gongfen over 12 years ago

Prodigy 60 points

Dear Sir,

I'm using a hdmi rx too. My hdmi rx work master mode and config 16bit I2S mode (Streo).

Then If I config mcbsp to this reg, and I will got only one channel, the other (left or right) channel is nothing data.

Use:

arecord -f cd -d 20 -r 44100 -c 2 -f S16_LE /tmp/test.wav&

My mcbsp's reg:

00 00000000

04 00000000

08 0200003f --SPCR

0c 00450140 --RCR

10 00000000

14 101f0f00 --SRGR

18 00000000

1c 00000000

20 00000000

24 00000085

SRGR.CLKSM = 0;

PCR.SCLKME =1

SRGR.FSGM = 1

PCR.CLKRP =1

PCR.FSRP = 1

SPCR.RINTM = 3

SPCR.FREE = 1;

RCR.RFRLEN=1; // 2 data words

RCR.RDATDLY=1; // 1 bit i2s data delay

SRGR.FWID=15; // 16 bit left+right

SRGR.FPER=31; // 2*FWID

RCR.RWDLEN1 = 2; // 16bit

So, can you check my problem?

0 Ivan Garcia over 12 years ago in reply to qiu gongfen

TI__Genius 9775 points

Could you share your waveforms for RX/FSR/CLKR (assuming you're only capturing)?

Processors

Processors forum

Capture I2S using external framing on DM365 McBSP