TMS320C6748: getting 2ch data concurrently in upp port

Hi,

My customer has tested more on this issue and it seemed they failed to get 2ch data in upp concurrently, and this is not a issue in ADC setting.

My customer's latest test was to connected 2ch upp ports to same ADC channel and generate test pattern in ADC. e.g. they connected both A and B channels of upp to same A channel of ADC. They expected same data were found in each upp buffers, but they found there were some difference between A channel buffer and B ch. buffer of upp at each time as below. 

They also found this difference between A ch and B ch was reduced when they increased CPU frequency.

e.g. in above table, you can find the difference values were 1 ~ 2 at 300Mhz CPU clock. When they increased CPU clock up to 456Mhz, they found this difference values were reduced to 0 ~ 1 at 456Mhz CPU clock.

Their SW is non-OS based bare-metal SW as below.

7242.UPP.C

Please let me know how they can get both A and B ch of upp concurrently without phase difference.

Thanks and Best Regards,

SI.

Mukul,

At this time, just as test, they connected same A ch. of ADC to A and B ch of upp. e.g. same data pins of ADC were connected to both A and B ch data pins of upp concurrently, and other data pins of ADC(e.g. ch.B) were disconnected. This is their configuration to check DSP upp ports and SW. So, I'm not sure if this is ADC related issue or not, and I think we need to make clear DSP related issue first.

For Timer, they are using timer just to check the performance of FFT. So, there is no need to use Timer at this time, but they are afraid there will be a need to use Timer in other product as they are willing to check all feasibility of C6748 platform at this time before applying it on real product.
And also, even when Timer was disabled and they set normal mode in ADC, the difference between ch.A and B of upp was varied between 0 ~ 1. This is an issue as they can not compensate it easily.
Anyway, I'll let them know how to use TSCL registers to measure FFT();

Do you think it can be an issue to connect 1ch data pins of ADC to 2ch data pins of upp?


For lower CPU frequency, they found more issues occurred and the difference was increased in lower CPU frequency(200Mhz).

For CVDD, they are not change CVDD voltage when change CPU frequency and their current CVDD voltage is 1.3V. As they have used the GEL file of our LCDK, they tested it with 300Mhz CPU frequency at first. They modified this GEL file only to increase CPU clock to 456Mhz.

I can share their source code if you need.

Thanks and Best Regards,
SI.

Hi Mukul,

Where you see adc_sclk?  I could not find it.

Is there any reference design HW and SW to connect ADC to upp port?

I found there are upp ports in C6748 and C6657/5/4/2, and it would be helpful it there are any examples to connect ADC through UPP 2 channels.

And also, what does meaning of 2way in below? does this mean full-duplex?

Thanks and Best Regards,

SI.

Hi Mukul,

Actually the difference in initial sample is not an issue and they can compensate it in this case.
But, the problem is the difference is occurred at anywhere and they can not compensate it when they input signal.

Could you please recommend sample size transferred by DMA at one time from upp?
I found they received large sample size to process FFT for large sample blocks, and they tried to test with 8192 samples and 16384 samples.
I'm worrying it takes too much time to I think we need to suggest more efficient architecture like ping-pong buffer. Could you please provide your opinion on this?

I found below e2e and it seemed block size(sample size) also impact on the performance and this is why I'm asking.
e2e.ti.com/.../719192



And also, I found there was a difference between test pattern and input signal. As I said before, there was no issue with test pattern, but they found unexpected difference at anywhere with real signal input. This is an issue to be resolved.
I found there was only FFT() function is working with real signal input although there was no FFT and only check difference between ch.A and B when they test with test pattern.

I think 8192pt FFT() function would impact the DMA performance.
But, my customer don't think this is an issue because they disabled DMA while FFT is working.

e.g. in their implementation, they got received 2ch 8192 samples each through upp, and disable DMA and run FFT.

Thanks and Best Regards,
SI.

Hi Mukul,

Thanks for response, and let me summarize as you requested.

Summary:

1. Frequency dependency

  ans) more issues in lower frequency. i.e. the difference is more dynamically varied in lower frequency.

2. Adjacent traffic (UART, Timers)

  ans) Timer impact the issue, but UART did not.

3. Test pattern vs Real input signal

  ans) Test pattern : there is no issue at 456Mhz. i.e. always 1 difference occurred between ch.A and B.

                                        there is an issue at 300Mhz. i.e. difference between A and B is varied 1 ~ 2.

            Input signal : there is an issue even at 456Mhz. i.e. difference between A and B is varied 1 ~ 2.

More information:

I think I found the difference between Test pattern and Real input signal(above summary 3).

I found there was no fft function in Test pattern and issue occurred at 456Mhz even with Test pattern when I insert fft function to be executed.

Based on below their test code, I think I can explain above summary 1 and 2.

As you see below, they implemented that they always do upp_setup and ADC setup at each iterations. I think the difference will be occurred at this upp_setup() and this is why it was impacted by CPU frequency and Timer ISR.

And also, I think this flow should be an issue and they need to modify to do upp_setup at initial time only. Are you agree?

full source code is also attached.

static void ADC_UPP_Test(void)
{
    volatile unsigned int *pADCChannelA;
    volatile unsigned int *pADCChannelB;

    unsigned int lwData;
    unsigned int lwXData;

    unsigned int lwIndex;
    unsigned char lbIndex;
    unsigned char lbReadData;
    unsigned int lbErrorCnt;

    fft_result lfrCurrentResult;
    fft_result lfrVoltageResult;

    ADS4242PWRDown(dDISABLE);
    ADS4242HWReset();
#ifdef ADC_PATTERN
    ADS4242RegSetup(dTEST_PATTERN_INCREMENT, 0x4567);
#else
    ADS4242RegSetup(dTEST_PATTERN_NORMAL, 0x4567);
#endif

    for(lbIndex=0;lbIndex<10;lbIndex++)
    {
        lbReadData = ADS4242RegRead(gbaADS4242_RegReadArray[lbIndex]);
        UartPrintf(dDEBUG_PORT, "\n\rADS Reg Read ADDR 0x%02x = 0x%02x",gbaADS4242_RegReadArray[lbIndex],lbReadData);
    }

    lbErrorCnt = 0;
    gfFFTLength = dFFT_SAMPLE_LENGTH;
    UPPSetup(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength);
    while(1)
    {
        //측정 대기 시간 추가 필요
        if(gwUPPISRCnt)
        {
            ADS4242PWRDown(dENABLE);
            IntEnable(C674X_MASK_INT5); //UART2
            IntEnable(C674X_MASK_INT6); //UART0
            //IntEnable(C674X_MASK_INT7); //Timer

#ifdef ADC_PATTERN
            pADCChannelA = (unsigned int *)dCURRENT_ADC_DATA_ADDR; //DMA-I == UPP_D0 ~ D15
            pADCChannelB = (unsigned int *)dVOLTAGE_ADC_DATA_ADDR; //DMA-Q == UPP_XD0 ~ XD15

            FFTProcess(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength,5e3,&lfrCurrentResult,&lfrVoltageResult,dENABLE);

            for(lwIndex=0;lwIndex<1;lwIndex++)
            {
                lwData = *pADCChannelA & 0x3fff;
                lwXData = *pADCChannelB & 0x3fff;

                if((lwXData-lwData) != 1)
                {
                    lbErrorCnt += 1;
                }

                UartPrintf(dDEBUG_PORT,"\n\r%d %x \t%x \t%x \t%x \t%d Error Cnt = %d",lwIndex,pADCChannelA,lwData,pADCChannelB,lwXData,lwXData-lwData,lbErrorCnt);

                //exit(1);


                pADCChannelA += 2;
                pADCChannelB += 2;
            }
#else
            FFTProcess(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength,5e3,&lfrCurrentResult,&lfrVoltageResult,dENABLE);
#endif
            Delay(dDELAY_TIME_100ms);
            Delay(dDELAY_TIME_100ms);
            Delay(dDELAY_TIME_100ms);

            ADS4242PWRDown(dDISABLE);
            ADS4242HWReset();
#ifdef ADC_PATTERN
            ADS4242RegSetup(dTEST_PATTERN_INCREMENT, 0x4567);
#else
            ADS4242RegSetup(dTEST_PATTERN_NORMAL, 0x4567);
#endif
            UPPSetup(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength);
        }
    }
}

~~~~~~~~~~~~

   ADS4242PWRDown(dDISABLE);

   ADS4242HWReset();

   ADS4242RegSetup(dTEST_PATTERN_INCREMENT, 0x4567);

   lbErrorCnt = 0;

   gfFFTLength = dFFT_SAMPLE_LENGTH;

   UPPSetup(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength);

   while(1)

   {

       //측정 대기 시간 추가 필요

       if(gwUPPISRCnt)

       {

           ADS4242PWRDown(dENABLE);

           IntEnable(C674X_MASK_INT5); //UART2

           IntEnable(C674X_MASK_INT6); //UART0

           //IntEnable(C674X_MASK_INT7); //Timer

           pADCChannelA = (unsigned int *)dCURRENT_ADC_DATA_ADDR; //DMA-I == UPP_D0 ~ D15

           pADCChannelB = (unsigned int *)dVOLTAGE_ADC_DATA_ADDR; //DMA-Q == UPP_XD0 ~ XD15

           for(lwIndex=0;lwIndex<1;lwIndex++)

           {

               lwData = *pADCChannelA & 0x3fff;

               lwXData = *pADCChannelB & 0x3fff;

               if((lwXData-lwData) != 1)

               {

                   lbErrorCnt += 1;

               }

               UartPrintf(dDEBUG_PORT,"\n\r%d %x \t%x \t%x \t%x \t%d Error Cnt = %d",lwIndex,pADCChannelA,lwData,pADCChannelB,lwXData,lwXData-lwData,lbErrorCnt);

               pADCChannelA += 2;

               pADCChannelB += 2;

           }

           Delay(dDELAY_TIME_100ms);

           Delay(dDELAY_TIME_100ms);

           Delay(dDELAY_TIME_100ms);

           ADS4242PWRDown(dDISABLE);

           ADS4242HWReset();

           ADS4242RegSetup(dTEST_PATTERN_INCREMENT, 0x4567);

           UPPSetup(dCURRENT_ADC_DATA_ADDR,dVOLTAGE_ADC_DATA_ADDR,gfFFTLength);

       }

   }

}

Thanks and Best Regards,

SI.

Hi SI

Sorry for the delayed response - unfortunately no bright ideas to further narrow down the issue. Responses to your questions

As I found there was no missing in DMA copy and just one value slipped in channel B, I'm doubting there should be an issue while data received in internal FIFO. And also, when I checked all values in the buffers, normally there was no issue and always the difference between end value and start value is 8191, but at sometimes, this value is over 8191, and this meant there was missing to receive data in upp. (window size is 8192. So, 8191 is right). this missing was occurred at both ch.A and ch.B.

Are you saying that it is always the last elements that have an issue? Can you try smaller /different packet/transfer size?

Do you think power can be a issue?
Their custom board is using USB power. I'm afraid this is not enough to run C6748 DSP and ADC.

Hard to say, you  had things somewhat working at lower frequency. I have not seen many USB powered c674x applications. Have they done board power measurements to ensure power is not an issue? Have they tried any other tests to see if they see any failures , if power design is a suspect?

The 

The exact part name of DSP is TMS320C6746-375Mhz, but they connected 1.3V to CVDD.
Do you think this can cause this issue?

I would recommend sticking to the max frequency supported by the device, so even though you are running the device at 1.3V , since it is a 375 MHz device, runnign at 456 MHz is running it out of spec and while personally i do not think this is the issue - I would recommend doing more testing at 300 MHz or 375 MHz only to root cause the issue. 

Their ADC's output CLOCK frequency connected to upp is 4.096Mhz, and I'm worrying if this is too low. Please let me know if you have any idea.

Do they have the ability to change the clock to test. 4 MHz clock does sound low , as upp is capable of higher. Did you confirm my previious query on adc_clk source from the schematic shared in the other e2e forum?

On your offline query on 3p suggestions for this - unfortunately i am not aware of any 3p that has a working upp+adc solution.

The only 3p with upp expertise i am aware of is Critical Link. They have boards that have upp to FPGA interface. 

Mukul,

Thanks for your response.
There is still an issue when ch.B moved to shared memory and the buffer of ch.B was allocated in shared memory. I have not tested it on L2 cache. To test it on L2 cache, I think I should set L2 cache to be freeze. do you have any example to make it freeze?

I'm afraid there is nothing to do more in SW wise, unfortunately. I implemented it using polling instead of interrupt previously, but issue is the same. I'm afraid there is no way to sync-up between ch. A and B in upp of C6748 or it is their custom HW issue. If there is not a logic to sync-up between ch. A and B, it should be natural the delay in ch.B will be different and could not be robust whenever it was executed, isn't it?
Is it possible to check their scenario and if the sync-up between ch.A and B when same clock source input?
Is it possible for you to check with 3P - Critical Link - for sync-up between ch.A and B?

To change ADC clock output, they need to change crystals for ADC clock input. So, it is not easy.
if we have any reasonable doubts on this low ADC clock, I will try to persuade them to change crystals, but it is hard to change at this time without any reason. Is it possible to check this also with Critical Link or Factory team?

I'm afraid it will be the time soon to decide if we will work on this further or give-up this opportunity.

If you can check with 3P or factory team, it would be very helpful.

I implemented it using polling, but there was still an issue.
I have checked their upp register settings, ISR routine, DMA settings, and PINMUX, but I could not find any strange thing and can not resolve issue.


Thanks and Best Regards,
SI.

Hi Mukul,

I think I find root cause of this issue although I'm still testing it.
I think the root cause is the timing of DMA setting between ch.A and ch.B(ch.I and ch.Q).
I think upp port started to work when DMA setting was done. So, I'm guessing there was time gap to set each DMA channel and this time gap cause the issue, and this explain why the delay gap was small in higher CPU frequency.

e.g. the original code is

~~~~~~~~~~~
// For DMA Channel I.
HWREG(SOC_UPP_0_REGS + UPP_UPID0) = ((unsigned long)plwUPP_DATA_ADDR << UPP_UPID0_ADDR_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPID1) = (lwLineCnt << UPP_UPID1_LNCNT_SHIFT) | \
(lwByteCnt << UPP_UPID1_BCNTH_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPID2) = (0 << UPP_UPID2_LNOFFSETH_SHIFT);

//For DMA Channel Q.
HWREG(SOC_UPP_0_REGS + UPP_UPQD0) = ((unsigned long)plwUPP_XDATA_ADDR << UPP_UPQD0_ADDR_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPQD1) = (lwLineCnt << UPP_UPQD1_LNCNT_SHIFT) | \
(lwByteCnt << UPP_UPQD1_BCNTH_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPQD2) = (0 << UPP_UPQD2_LNOFFSETH_SHIFT);

~~~~~~~~~

When I changed it as below, I found the delay gap was reduced.

~~~~~~~~~
// For DMA Channel I and Q. interleaved DMA settings
HWREG(SOC_UPP_0_REGS + UPP_UPID0) = ((unsigned long)plwUPP_DATA_ADDR << UPP_UPID0_ADDR_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPQD0) = ((unsigned long)plwUPP_XDATA_ADDR << UPP_UPQD0_ADDR_SHIFT);

HWREG(SOC_UPP_0_REGS + UPP_UPID1) = (lwLineCnt << UPP_UPID1_LNCNT_SHIFT) | \
(lwByteCnt << UPP_UPID1_BCNTH_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPQD1) = (lwLineCnt << UPP_UPQD1_LNCNT_SHIFT) | \
(lwByteCnt << UPP_UPQD1_BCNTH_SHIFT);

HWREG(SOC_UPP_0_REGS + UPP_UPID2) = (0 << UPP_UPID2_LNOFFSETH_SHIFT);
HWREG(SOC_UPP_0_REGS + UPP_UPQD2) = (0 << UPP_UPQD2_LNOFFSETH_SHIFT);
~~~~~~~~~~~~

Do you think this my guess is reasonable?

Current my solution is to enable upp register at last.

~~~~~~~~~~~
//0. Reset the EN bit in the uPP peripheral control register (UPPCR) to 0 to turn off the uPP peripheral.
HWREG(SOC_UPP_0_REGS + UPP_UPPCR) &= ~(UPP_UPPCR_EN);
uppcr_status = HWREG(SOC_UPP_0_REGS + UPP_UPPCR) & (UPP_UPPCR_DB);
while (uppcr_status) {
uppcr_status = HWREG(SOC_UPP_0_REGS + UPP_UPPCR) & (UPP_UPPCR_DB);
}

:
:
(upp register settings)

:

(DMA channel settings)

//7. Set the EN bit in the uPP peripheral control register (UPPCR) to 1 to turn on the uPP peripheral.
// To sync-up between ch.A and B
saveReg = HWREG(SOC_UPP_0_REGS + UPP_UPPCR) & \
~(UPP_UPPCR_EN | UPP_UPPCR_RTEMU | UPP_UPPCR_SOFT | UPP_UPPCR_FREE);
HWREG(SOC_UPP_0_REGS + UPP_UPPCR) = saveReg | \
(0x00000001u << UPP_UPPCR_EN_SHIFT);

~~~~~~~~~~~~

Do you have any idea to sync-up each upp port start time better than this?
Do you think this is right solution to sync-up upp channels?

At very few times, I found mismatched value between ch.A and B. so, if you have better idea, it would be very helpful.
And also, in TRM document of C6748, the order of 'upp enable set' was 7th before DMA settings. my solution is to place it in the last.
I would like to check if there is any reason to place it on 7th order in TRM and it is OK to place it in last after DMA settings.

Thanks and Best Regards,
SI.

Hi SI

Thanks for updating the post with the latest status. I apologize for not being able to provide you any additional closure on this - your previously requested need for guidance on 3P route is also not very viable, as I am not aware of any 3P that specifically has uPP with ADC running. 

Looks like there is some improvement in the overall robustness, but still some failures - where does that leave you with closing this out with the customer?

Quick glance at the code, I don't find any additional issues to point to. 

Are the failures still more prominent at lower frequency after implementing all the changes you mentioned in your last post?

Regards

Mukul