TAS1020B USB Transfers

Praveen,

 Your posting indicates that you’re setting DMATSH1 to 0xC0, for 4bytes/time slot.

Are you really transferring 32-bit audio to the host?  I’d guess that you would want either 0x40 (for 16-bit audio) or 0x80 (for 24-bit audio). 

I constructed a somewhat-similar setup in the past, for 4 channels of 16-bit audio, using the following setup:

 void coInitCodec()

{

    if (!coCodecInited)

    {

        USBIMSK &= ~0x10;

        softPllInit();

        USBIMSK |= 0x10;

        coInitADCs();

        // configure DMA      

        DMATSH0  = 0x40;     // 2 BYTEs per time slot OUTBOUND

        DMATSL0  = 0x03;     // Slots 0&1

        DMACTL0  = 0x01;     // Out EP1 to C-port

        DMACTL0 |= 0x80;     // enable OEP1

        DMATSH1  = 0x40;     // 2 BYTEs per time slot

#if( DEV_NUM_MIC_CHANNELS == 2 )

        DMATSL1  = 0x05;     // Slots 0&1 - stereo mic in rd 2004.11.04

#else

        DMATSL1  = 0x0f;     // Slots 0&1&2&3 - quad mic in rd 2004.11.04

#endif

        DMACTL1  = 0x0A;     // In EP2 from C-port     

        DMACTL1 |= 0x80;     // enable EP2 from C-port 

        // disable C-port 

        GLOBCTL &= ~CODEC_PORT_ENABLE;

        // Configure the C-port  

        CPTCNF1 = 0x0C;     // I2S mode4

        CPTCNF2 = 0xCD;     // 16-bit per time slot 

        CPTCNF3 = 0xAC;         // byte inverse & 1clk delay

        CPTCNF4 = 0x03;     // CSCLK = MCLK/4

        // Enable C-port

        GLOBCTL |= CODEC_PORT_ENABLE;

        coCodecInited = TRUE;

    }

}

 > The example firmware that i modifes had setup the ISOC USB buffers as a circular buffer and with its size equal to the Max Endpoint packet size

The size of the circular buffer needs to be ~2x the size needed for the transfer to the host.

If you are doing 16-bit audio, the buffer should be about 2*32*4(channels)*2(bytes/sample for one channel), or

16-bit:  512Bytes

24-bit: 768Bytes

32-bit: 1024Bytes

Using CPTCNF3 = 0xAF to attempt to set CSCLK and CYNSC as inputs to the TAS1020B is not effective.  When set to Mode 4 for I2S, CSCLK and CYNSC are necessarily outputs from the TAS1020B, as per Table 1-4.

 Regards,

Frank

For the record, the problem turned out to be that the code (likely copied from the FDK routine) was invoking STALLClrInEp2 after having correctly setup IEPCNF2.

Since hwmacro.h provides the macro's definition as

#define STALLClrInEp2  {IEPCNF2 &= ~0x08;}

this had the effect of clearing a bit in BPS ("bytes per sample"). 

[When set for isochronous transfers, IEPCNFx has a different format than for control/bulk/interrupt transfers - and there is no STALL bit.]

Eliminating the invocation of STALLClrInEp2 resulted in correct functioning.

Frank,
This was a really good debug. I guess i wasn't looking for settings in the ROM code. It would have been solved a lot quicker that way. Thanks for taking the time.

Thanks,

Praveen 

Hello Frank,

The board that I was working on previously had PIN 32 (CSCHNE or SDIN2) connected to ground. So until now I was not able to test if there was data on SDIN2 line as it would always be 0 . Now I have a new board which doesn’t have  SDIN2 tied to ground and its connected to a second ADC. I have probed the ADC output and I get data on it. But the USB sniffer always gives me 0’s in time slots 1 and 3 where it is supposed to taking the data that’s on the line SDIN2. Do you see a problem with my configuration that would cause this ? Did you verify all the four channels of the Microphone and if you were getting valid data in all of them at the same time in the previous Project that you had sent me. Here is a screenshot of what I see on the USB bus. 

Please let me know if there is any way of verifying that the DMA is actually getting the data on SDIN2 on timeslots 1 and 3 because I cannot see any data on the USB sniffer.

Praveen,

> Did you verify all the four channels of the Microphone and if you were getting valid data in all of them at the same time in the previous Project that you had sent me.

At the time, I only had a stereo source, but I heard output from Windows when that stereo source was supplied to the L/R input, and to the Ls/Rs input.

I suggest that you load the project I sent into the EVM2 and try it yourself.

Frank

Frank,

I think the problem is with SDIN2 when the data is 32 bit. Here s what i have tried. I setup the device to be a 4 channel microphone wih 32 bit resolution. So the DMA was supposed to get 32 bits in each time slot. Now this works fine with data coming in on SDIN1. The DMA pads the 24 bit data from the codec with 00's in its LSB and writes nthem into the USB Buffers. But it is not able to do the same with data coming in on SDIN2. In order to further investigate, i configured the device to be a 2 channel Microphone with and made DMATSL1  = 0x0A (only time slots 1 and 3 active) so that the DMA is only sampling data from the SDIN2 line. With this if i set the DMATSH1  = 0xC0 and CPTCNF2 = 0xED to get 32 bits per time slot, i get only 0's. But if i change the register values to get only 24 bit per time slot, then i get valid data. So what works for SDIN1 doesnt work for SDIN2. Has anyone ever tried it to use SDIN2 with 32 bits resolution before. I remember you mentioning something about not being able to do 32 bit resolution ?

thanks,

Praveen

Frank,

I am trying to setup the UART in the TAS part. I see that you have used the UART in the example project that you have sent me. Can you please tel me where you are initialising the UARTModes and setting up the Baud rate for the UART communication. I can find the setting made to SFR bits SCON anywhere in the source files. Can you please point me to the files where these settings have been made.

THanks,

Praveen

Frank,

Never Mind i found it. I was looking in the wrong project

Frank,

I am trying to use the UART in the example code that you have sent. I have the follwing settings

SCON = 0x53; // 8-bit serial tx and rx, TI set so ready to tx
T2CON = 0x30; // use timer 2 as uart TX and RX timer // at this point, the MPU clock is 12MHz
RCAP2H = 0xff; // set 19.2kHz when MPU clock is 12MHz
RCAP2L = 0xed; // for 19.2kHz
TR2 = TRUE; // start timer 2 running

I am able to receive data from the Device but i am not able to transmit. The RI bit of SCON register is never getting set. On further investigation i found that the UART Rx Line of the Device (Pin 3.0) is pulled low by the device. Is there any other register we need to write into to make this pin behave as an input(Pulled high), so as to be able to receive data from the host.

Thanks,

Praveen

Praveen,

That code works on the EVM2.  Why don't you get your hands on one of them?

Frank

Frank,

Is there a way to send a zero length data packet on an endpoint that has been configured as BULK. I tried to do it by setting IEPDCNTX = 0x00 . But although this transfers a zerolength packet on the USB bus, the core never sets the NACK bit in IEPDCNTX to 1. IS there another way to do a zerolength transfer on the USB bus. PLease let me know since it is required by the host applicaiton i am using to talk to TAS1020.

THanks,

Praveen

Praveen,

I ran up against the same problem many months ago.  I was able to get the ZLP to go out, but exactly how I don't remember - and I don't have the source for what I did.  I do remember trying to configure the EP as isochronous, and maybe that was the key.  But there was another problem that resulted:  there was no indication that the ZLP was acknowledged, so you didn't know if you needed to send it again.  I was pulled-off before going any further, but thought that if, at the application level, your code would recognize that the ZLP appeared to be ineffective and if so send it again, perhaps that would work.

Good luck,

Frank

Frank,

thanks for the response. I do not have the liberty of configuring the endpoint to be isochronous. this is required on a bulk endpoint. Secondly when i tried sending a ZLP in the way i have explained above, the data0 to data1 toggle doesn't occur and host repeatedly asks for IN packets as if it did not recognise the ZLP being sent. The device is clearly not happy with sending a ZLP on a bulk endpoint. I am not sure if there is a special register (hidden) that can be set to some value to achieve this. I am getting around this problem by sending a short packet (which i throw away on the host) everytime the data length of the transfer is a multiple of the max packet size boundary (64) of the bulk endpoint. Do let me know if you come across any other way of doing this on a bulk endpoint.

Thanks,

Praveen