This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28335: Absurd ADC values on ezdsp Dev. board

Other Parts Discussed in Thread: TMS320F28335

Hello everyone,


I recently purchased a ezdspf28335 development board for a company project. I need to sample ADC values but I can't get the ADC to work correctly. The problem is reproducible with all the TI's ADC Examples.

For the post, let's consider the Example_2833xAdcSeqModeTest which pretty simple and quite similar to my future ADC implementation. This example basically uses the Cascaded mode to sample the ADCINA0 channel.

Problem : 

I put a breakpoint to inspect the conversion results:

- When nothing is connected to the ADCINA0 pin, I get random 0-4095 values like 933 / 3013 / 2829 / 1194 / 2381... : OK, why not.

- When ADCINA0 is connected to the GND (P9.1 on the Dev. board), the values are lower but still crazy and always changing : 110 / 180 / 413 / 477 / 293 / sometimes 0 / ....

I really do not understand this issue. Values should be stable and extremely low (~ 0) when ADCINA0 is connected to the Ground !

I made the following checks:

Hardware checks :

- The ADCLO pin is connected to AGND as required.
- The ADCREFIN jumper (JP1) is opened, because the example configures the ADC to use the internal reference voltage.
- According to the Dev board schematic in the datasheet (ezdspf28335c_techref), ADC pins connections are correctly set-up (ADCRESEXT, ADCREFP, ADCREFM, VDD1A18, VDD2A18, VSS1AGND, VSS2AGND, VDDA2, VSSA2, VDDAIO, VSSAIO) conforming to figure 4.9 "ADC Pin Connections with Internal Reference" in the tms320f28335 manual.

Software checks :

- The ADC clock seems to be correctly set-up in the example code and does not exceeds the 25 MHz limit.
SYSCLKOUT = 150 MHz, HSPCLK is specifically reduced to 25 MHz, then ADCCLKPS = 2 so ADC Module clock = 12.5 MHz
(So this problem : http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/160912.aspx#596971 does not apply in the example code I choosed).
- The Sample / Hold width is set at its maximum value (0xF)
- Other things are set-up pertinently:
           => Cascaded Mode
           => Continuous Run
           => CONV00 = 0 to sample ADCINA0

- I saw no relevant problem report in the device errata sheet

I'm running out of solutions. I think it is a hardware problem rather than a software problem but the dev board seems to be "ADC-ready-to-use".

Any help would be greatly appreciated,

Regards


The example code :

// ADC start parameters
#if (CPU_FRQ_150MHZ)     // Default - 150 MHz SYSCLKOUT
  #define ADC_MODCLK 0x3 // HSPCLK = SYSCLKOUT/2*ADC_MODCLK2 = 150/(2*3)   = 25.0 MHz
#endif
#if (CPU_FRQ_100MHZ)
  #define ADC_MODCLK 0x2 // HSPCLK = SYSCLKOUT/2*ADC_MODCLK2 = 100/(2*2)   = 25.0 MHz
#endif
#define ADC_CKPS   0x1   // ADC module clock = HSPCLK/2*ADC_CKPS   = 25.0MHz/(1*2) = 12.5MHz
#define ADC_SHCLK  0xf   // S/H width in ADC module periods                        = 16 ADC clocks
#define AVG        1000  // Average sample limit
#define ZOFFSET    0x00  // Average Zero offset
#define BUF_SIZE   2048  // Sample buffer size

// Global variable for this example
Uint16 SampleTable[BUF_SIZE];

main()
{
   Uint16 i;
   Uint16 testResult;

   testResult = 0;

   InitSysCtrl();

// Specific clock setting for this example:
   EALLOW;
   SysCtrlRegs.HISPCP.all = 0x11;//ADC_MODCLK;	// HSPCLK = SYSCLKOUT/ADC_MODCLK
   EDIS;

// Disable CPU interrupts
   DINT;

// Initialize the PIE control registers to their default state.
   InitPieCtrl();

// Disable CPU interrupts and clear all CPU interrupt flags:
   IER = 0x0000;
   IFR = 0x0000;

// Initialize the PIE vector table with pointers to the shell Interrupt
   InitPieVectTable();

   InitAdc();  // For this example, init the ADC

// Specific ADC setup for this example:
   AdcRegs.ADCTRL1.bit.ACQ_PS = ADC_SHCLK;
   AdcRegs.ADCTRL3.bit.ADCCLKPS = ADC_CKPS;
   AdcRegs.ADCTRL1.bit.SEQ_CASC = 1;        // 1  Cascaded mode
   AdcRegs.ADCCHSELSEQ1.bit.CONV00 = 0x0;
   AdcRegs.ADCTRL1.bit.CONT_RUN = 1;       	// Setup continuous run


   // Start SEQ1
   AdcRegs.ADCTRL2.all = 0x2000;

   // Take ADC data and log the in SampleTable array
   for(;;)
   {
     for (i=0; i<AVG; i++)
     {
        while (AdcRegs.ADCST.bit.INT_SEQ1== 0) {} // Wait for interrupt
        AdcRegs.ADCST.bit.INT_SEQ1_CLR = 1;

        testResult = (AdcRegs.ADCRESULT0>>4);
     }
   }
}

  • Hi Florian,

    One quick question, are all ADC channels behaving the same?

    Regards,

    Gautam

  • Yes, the behaviour is the same for all channels

  • Florian DELAUNAY said:
    Yes, the behaviour is the same for all channels

    For checking purpose, can you use a RC filter towards ADC? This will give us an idea whether the board is noise prone or not. Also, how are you powering the kit? Computer USB port?

    Regards,

    Gautam

  • Hi Florian,

    To expand a little bit on Gautam's points:

    The best way to start experimenting with the ADC is to use something like a function generator to supply a DC mid-scale voltage (maybe something in the 1V-2V range).  An RC filter can also be helpful, with preference on low R and high C.


    The next step after checking the development kit schematic is to check the actual voltages.  Can you confirm that all the supply rails and ADC support pins are at the intended voltage?  This will go a long way towards ruling out any HW issues.

  • The eZdsp board is powered via a 230 V to 5V AC/DC supply. All the ADC supply rails are at the intended voltage.

    I did other tests with a DC Generator and the values are still very noisy but relatively coherent with the applied voltage. The variation range is +/- 300 LSB, but I noticed on the oscilloscope that the voltage on the ADC pin is noisy: +/- 50 mV variations. The moving average value is OK with a +/-10 LSB variation. I think there's a Gaussian noise, which explains why the smoothed average value is relevant.

    I think the eZdsp board is not made for accurate ADC experimentation. Moreover, other ADC pins are not connected and that's a bad thing for the accuracy of the conversion (interference ?).

    For the moment that's OK for me, I think the ADC works correctly from a software point of view.

    I'm waiting for a first board prototype from my hardware team and I hope the signals will be less noisy.

    I will keep you updated if I have any problems (or not) with a cleaner board design.

    Thank you for your recommendations

    Regards

  • Florian DELAUNAY said:

    I'm waiting for a first board prototype from my hardware team and I hope the signals will be less noisy.

    I will keep you updated if I have any problems (or not) with a cleaner board design.

    That sounds good. Do keep us updated.

    Regards,

    Gautam