TUSB3200

Hasebe-san,

> In addition, the data is transferring 192 bytes in size and normal frames before and after the symptom.

This seems to point toward the problem.  When you switch to 44.1kHz, you should start seeing 176 and 180 byte packets.

When you switch from 48kHz to 44.1kHz, the ACG settings should change so that the SCLK and LRCK to your ADC is appropriate for 44.1kHz.  Do you see that?

The DMA should remain operational throughout.

Could you post a USB bus trace which shows the problem?  I have capability to read Lecroy, Total Phase, and Ellisys formats.

Regards,

Frank

Hello,　Frank-san

I　get the USB data and send to you.

Please check this data.

Best Regards,

Y.Hasebe

Hello, Frank-san

I will send to you USB data attached sheet.

Please check  this data.

Best Regards,

Y.Hasebe8420.TUSB3200_USBdata.pptx

Hasebe-san,

Can you please post the .usb file (or email it to me at fminich@ti.com)?  I want to see the configuration descriptor that the TUSB3200 provides to the host, and the control transfer that the host uses to set the sample rate to 44.1 (which doesn't appear to have any effect).

Also, it appears that, if in fact the set_sample_rate command is sent correctly, it is ineffective.  Have you looked at the frequency of the SCLK output from the TUSB3200 both before and after the switch from 48000Hz to 44100Hz is made?

Regards,

Frank 

Hasebe-san,

Note that if you are basing your work on the Firmware Development Kit for the TUSB3200:

- the 'EVM' example uses an AC97 codec, which _always_ uses 48kHz on the 'AC-link' between the codec and the 'controller', no matter whether the audio is 32kHz, 44.1kHz, or 48kHz.

- the 'EVM2' examples use an I2S codec, but there are different builds for different sample rates;  you would need to handle the set_sample_rate command and select the appropriate ACG parameters based on the selected sample rate.

Regards,

Frank

Ｈｅｌｌｏ　Frank-san,

I'm sorry for the late late reply.

Hello　Frank-san、

> What has been confirmed both before and after switching from 48000Hz to 44100Hz frequency of SCLK output from the TUSB3200?

This question is your question, not my((customer) question.

Then customer's answer is as follows.

⇒It is the question of the frequency is correct before and after switching 44.1kHz/48kHz.

Also、I sent to your Email address .USB file .

Could you receive it ? 

Best Regards,

Y.Hasebe

Hello Frank-san,

Hello Frank-san,

I sent  .USB files twice(14,Mar.& 27 Mar.)  to your Email address.

Could you receive them?

Also ,please teach me about your additional questions on March 27.

Best Regards,

Y.Hasebe

Hasebe-san,

Yes, I received them and am able to view them in LeCroy's USB Protocol Suite.

I don't yet really understand the problem, and will spend more time tomorrow with the captures.  In the From44_1k_To48k(error).usb file, packet 123949 is apparently the set_sample_rate command, and after that the incoming isochronous packets have sizes 192 Bytes, which looks OK for 48kHz.  Prior to that, the sizes are 176 or 180 Bytes, which is appropriate for 44.1kHz.

So, I'm not sure what the problem is.  Can you please explain?

Thanks,

Frank

Hello Frank-san,

Hasebe-san,

Thanks to your spreadsheet, I see the anomaly in packet 130007 in your previous 'From44_1k_To48(error).usb' file.  This is a very strange problem, one I had not seen previously.  In this case, after successfully switching from 44.1kHz to 48kHz and having provided 43 good isochronous data packets for 48kHz, the the TUSB3200A provides a single zero-length audio packet, and then resumes sending valid 48kHz data.

Further, the data in the immediately-preceding audio transfer and the immediately-following audio transfer looks OK.  It's just this one packet that is bad.

This 43ms delay seems too long for the problem to be associated with the clock change at the circuitry level.

It will be very difficult to replicate this problem, since the configuration descriptor indicates that some of the interfaces are vendor-specific.

1.  Is the problem repeatable (i.e., does it happen on _every_ 44.1k->48k transition)?

2.  If so, is it always the 44th 48kHz audio packet that is zero-length?

3.  For debug purposes, if the program is modified so that it enters a tight program loop following the sample rate change (so that the program makes no subsequent changes to any registers at the 'program' level, but just performs interrupt-level processing), does the problem remain?  [I ask this because the program loop seems like it might be able to 'delay' some register setting by ~43ms.]

4.  If you monitor the MCLK and BCLK through the transition, is there any anomaly after the sample rate change that might account for this?

5.  Does the problem occur on more than one TUSB3200A?

6.  Is it possible to disable DMA for some duration following sample rate change, and if this is done, does the problem remain once DMA is re-enabled?

7.  Does the program monitor the OVF bit?  Is this bit being set?

8.  Does the problem occur with WABEN set?  with WABEN clear?

9.  If the configuration descriptor changes the maximum transfer from 192 to 196 bytes, and the buffers are similarly enlarged, does the problem remain? [Possibly there might be a slight mismatch in clock rate and the codec sends slightly too much data in the previous frame, so that buffer overrun occurs.] 

I apologize for responding to you with a list of questions, but as I say, I've not seen this problem previously, and recreating your setup here will be difficult.

Best regards,

Frank

Hello　Frank-san,

Thank you for your　information.

Now, I had already sent your questions and situation  to the customer ,but still can't get his answers.

Hasebe-san,

The question with regard to OVF is primarily one of trying to debug the source of the problem, but yes, when the application notes that the OVF bit is set, it should somehow 'log' the event (perhaps by bumping a counter which is available via LED display or UART interface) and clearing the OVF bit.  That's just so that we could figure-out how often overflow happens.

Best regards,

Frank

Hello Frank -san,

Thank  you  for your reply and I'm sorry to ask each other many times.

I have received information for the customer today.

He received from your some advices at last time, then increase the size and the maximum packet size of the endpoint buffer descriptor referring to the following, the symptoms of the problem did not occurs.

====================================================================

9.? If the configuration descriptor changes?the maximum transfer?from 192 to 196
bytes, and the buffers are similarly enlarged, does the problem remain?
[Possibly there might be a slight mismatch in clock rate and the codec sends
slightly too much data in the previous frame, so that buffer overrun occurs.]

=====================================================================

For starting this correspondence, he is anxious that some.
It is as follows.

Q1: Will it be reasonable to change the size of the descriptor and the buffer size that you have made to deal with this as OVF?

Q2: Do I set the buffer size and number of the packet size in order not to OVF?
Depending on the status of the clock, I think that would be considered to OVF even if you set the buffer size to 200 bytes?

Q3: I think I have tried to change the buffer size and packet size on the end point of the transfer Isochronous In.
Should the large size of the transfer for the endpoint Isochronous Out as well?

And also he asked additional question as follows.

Hasebe-san,

1. Changing the descriptor and buffer size as you have done is not a bad solution, but it's not quite right in that the endpoint descriptor still indicates 'synchronous', so it should always provide 48 samples (i.e., sample-pairs) when set to 48kHz.  You can instead set the endpoint to indicate 'asynchronous' or try to fixup the soft pll to track more-closely the USB clock.

2.  With the audio streaming endpoint set to 'asynchronous', it can legally send +/- 1 sample in each frame, so 196 is OK.  If the pll is off far-enough to send two additional sample-pairs, I think that could be problematic - so I would not do that.

3.  The host typically has plenty of resources so can do sample rate conversion if it needs to for synchronous output.  In my experience, the host always honors a 'synchronous' out endpoint request from the standpoint of _not_ sending -1 or +1 sample.

I attach softPLL.c from another project;  I hope that helps.

//================================================== 
// Texas Instruments 
// Copyright 1999, 2011, Texas Instruments Inc. 
//================================================== 
/*================================================== 
Softpll.c: routines to handle ACG soft PLL
//================================================*/
#include <Reg52.h>
#include "..\inc\types.h"
#include "..\inc\Reg_stc1.h"
#include "Softpll.h"

/*
**  Table of initial constants values for setting up ACG PLL
**  This setup assumes that MCLKO should be the following function
**  of the sample rate:
**     sampleRate * 64 * 8
**  where the factor of 64 is to allow for the 64 bit times associated with I2S
**  and the factor of 8 is for the overclocking factor.
**  This assumes that MCLKO is used, and is a function of the ACG
**  (i.e., not MCLKI)
*/
SOFTPLL_CONST code SoftpllConst[] = 
{ //  rem, quot , ACGFRQ0, ACGFRQ1, ACGFRQ2, ACGDCTL, ACGCTL, period
    { 000,  8192,    0x00,    0x7C,    0x92,    0x10,   0x44,    1   }, // 32k
    { 600, 11289,    0xE2,    0x4A,    0x6A,    0x10,   0x44,    5   },//44.1k
    { 000, 12288,    0x00,    0xA8,    0x61,    0x10,   0x44,    1   }, // 48k
};

// Globals Definiton
bit SoftAcgFirstTime;
WORD SoftRefAccumulator;
WORD SoftRefRemainder;
WORD SoftRefQuotient;
WORD SoftAcgCap1;
WORD SoftAcgCap2;
WORD SoftAcgAcc;
WORD SoftFrqDAcgAcc;
WORD SoftErrDelta;
byte SoftFreqUpdateCount;
byte SoftDefFredUpdateCount;

/*====================================================================
softPllInit(): USB ACG initialization
=====================================================================*/
void softPllInit(byte Index)  
{   
    SoftFreqUpdateCount = 0;
    SoftRefAccumulator = 0;
    SoftAcgFirstTime = 1;
    SoftRefRemainder = SoftpllConst[Index].remainder;
    SoftRefQuotient = SoftpllConst[Index].refQuotient;

    ACGFRQ1 = SoftpllConst[Index].defAcgfrq1;
    ACGFRQ2 = SoftpllConst[Index].defAcgfrq2;
    ACGFRQ0 = SoftpllConst[Index].defAcgfrq0;    
    
    ACGDCTL = SoftpllConst[Index].defAcgdctl; 	
    ACGCTL = SoftpllConst[Index].defAcgctl;
 
    SoftDefFredUpdateCount = SoftpllConst[Index].defUpdatePeriod;   
}

/*====================================================================
softPll(): ISR for Start of Frame which is used for 
the synchronous mode
=====================================================================*/
void softPll() 
{
    SoftAcgCap2 = SoftAcgCap1;
    
    LOW(SoftAcgCap1)  = ACGCAPL; // read capture register 
    HIGH(SoftAcgCap1) = ACGCAPH;
    
    if (SoftAcgFirstTime) 
    {	
        // make sure SoftAcgCap2 hold last acgcap reg value
        SoftAcgFirstTime=0;
        SoftAcgCap2=SoftAcgCap1;
        SoftErrDelta = 0;
    }
    else 
    {  
        if (SoftAcgCap1 < SoftAcgCap2) 
        {
            SoftErrDelta = 65536 - SoftAcgCap2;
            SoftErrDelta += SoftAcgCap1;
        } 
        else   
            SoftErrDelta= SoftAcgCap1 - SoftAcgCap2;
        
        SoftRefAccumulator+=SoftRefRemainder;
        if(SoftRefAccumulator>1000)
        {
            SoftRefAccumulator-=1000;
            SoftErrDelta = SoftRefQuotient + 1 - SoftErrDelta; //11290 - delta
        }
        else
            SoftErrDelta = SoftRefQuotient - SoftErrDelta;    // 11289-delta
    }
    
    SoftAcgAcc=SoftAcgAcc+SoftErrDelta;	    // accumulate error
    
    SoftFrqDAcgAcc = SoftFrqDAcgAcc - (SoftAcgAcc ); // correction every 1 ms
    SoftFreqUpdateCount++;
    if (SoftFreqUpdateCount == SoftDefFredUpdateCount)
    {
        SoftFreqUpdateCount = 0;
        SoftFrqDAcgAcc = (SoftFrqDAcgAcc >> 5) - (SoftAcgAcc << 2);
        
        ACGFRQ1 = HIGH(SoftFrqDAcgAcc);
        ACGFRQ0 = LOW(SoftFrqDAcgAcc);
    }  
}

Best regards,

Frank