• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1618 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

ADC Result 0 on Custom PCB F28069

Matthew Krenik
Intellectual 675 points
Other Parts Discussed in Thread: CONTROLSUITE

Hello,

I've set up a custom PCB with the F28069 on it. I am using 5 ADC channels, which are biased at 1.65 V. VREF-HI is set at 3.3V and VREF-LO is set at GND. 

I'm using some test software to see the device running and all other functions on the board are working except the ADC. To test the ADC, I initialize the ADC with the code at the bottom of the page. Then, I individually force each SOC with software and look at the ADCRESULT .

ADCRESULT0 is close to 4095 (which corresponds to 3.3V on the 12-bit ADC). This value should be incorrect.

All the other ADCRESULTS are close to 2000 (which corresponds to ~1.65V on the 12-bit ADC). These values seem to be correct.   

When I check the inputs to all of the pins, they are all at just about 1.65V, even the pin that feeds to ADCRESULT0. What is the issue here? Why is one of the ADC channels incorrect, but all of the other ones correct? 

Thanks,

Matthew 

ADC Initialization Code: 

EALLOW;
AdcRegs.ADCCTL1.bit.ADCBGPWD = 1; // Power up band gap
AdcRegs.ADCCTL1.bit.ADCREFPWD = 1; // Power up reference
AdcRegs.ADCCTL1.bit.ADCPWDN = 1; // Power up rest of ADC
AdcRegs.ADCCTL1.bit.ADCENABLE = 1;// set timing to 13cycles as required by ADC module

for (i = 0; i < 10000; i++) {
} // wait 60000 cycles = 1ms (each iteration is 12 cycles)

AdcRegs.ADCCTL2.bit.CLKDIV2EN = 1;
AdcRegs.ADCCTL2.bit.CLKDIV4EN = 0;
AdcRegs.ADCCTL2.bit.ADCNONOVERLAP = 1; // Overlap is not allowed

AdcRegs.ADCSAMPLEMODE.bit.SIMULEN0 = 0;
AdcRegs.ADCINTSOCSEL1.bit.SOC0 = 0; // No ADCINT triggers SOC0. TRIGSEL field determines trigger.
AdcRegs.ADCINTSOCSEL1.bit.SOC1 = 0;
AdcRegs.ADCCTL1.bit.INTPULSEPOS = 1;
AdcRegs.SOCPRICTL.bit.RRPOINTER = 0xF;
AdcRegs.SOCPRICTL.bit.SOCPRIORITY = 0;// All SOCs handled in round-robin mode

// Configure ADC

AdcRegs.ADCSOC0CTL.bit.CHSEL = 0;
AdcRegs.ADCSOC0CTL.bit.TRIGSEL = 0;
AdcRegs.ADCSOC0CTL.bit.ACQPS = 6;//set SOC0 S/H Window to 8 ADC Clock Cycles, (8 ACQPS plus 1)

AdcRegs.ADCSOC1CTL.bit.CHSEL = 1;
AdcRegs.ADCSOC1CTL.bit.TRIGSEL = 0;
AdcRegs.ADCSOC1CTL.bit.ACQPS = 6;//set SOC0 S/H Window to 8 ADC Clock Cycles, (8 ACQPS plus 1)

AdcRegs.ADCSOC2CTL.bit.CHSEL = 2;
AdcRegs.ADCSOC2CTL.bit.TRIGSEL = 0;
AdcRegs.ADCSOC2CTL.bit.ACQPS = 6;//set SOC0 S/H Window to 8 ADC Clock Cycles, (8 ACQPS plus 1)

AdcRegs.ADCSOC3CTL.bit.CHSEL = 3;
AdcRegs.ADCSOC3CTL.bit.TRIGSEL = 0;
AdcRegs.ADCSOC3CTL.bit.ACQPS = 6;//set SOC0 S/H Window to 8 ADC Clock Cycles, (8 ACQPS plus 1)

AdcRegs.ADCSOC4CTL.bit.CHSEL = 4;
AdcRegs.ADCSOC4CTL.bit.TRIGSEL = 0;
AdcRegs.ADCSOC4CTL.bit.ACQPS = 6;//set SOC0 S/H Window to 8 ADC Clock Cycles, (8 ACQPS plus 1)

  • 0
    TI__Guru 62975 points

    Matthew,

    Can you try a few experiments to see if the problem is a timing issue or a hardware related issue?

    1. Add SOC5 to sample channel 0 again at the end of RR sequence
    2. Reorder the channels in the RR sequence
    3. Add another set of SOCs to sample all of the channels again, but wait 500 cycles after the completion of the first set of SOCs before triggering the second set of SOCs

    -Tommy

  • 0 in reply to tlee
    Intellectual 675 points

    Hello Tommy,

    Thanks for your suggestions. Just to clarify, I'm not triggering all of the SOCs at once and relying upon the RR, I'm actually individually triggering each SOC, like below: 

    AdcRegs.ADCSOCFRC1.bit.SOC0 = 1;

    AdcRegs.ADCSOCFRC1.bit.SOC1 = 1;

    AdcRegs.ADCSOCFRC1.bit.SOC2 = 1;

    AdcRegs.ADCSOCFRC1.bit.SOC3 = 1;

    AdcRegs.ADCSOCFRC1.bit.SOC4 = 1;

    I tried your #1 suggestion by adding SOC5, also on Channel 0, but unfortunately, I got similar ADC results (value close to 4095). I have also tried reordering the sequence that I call the force SOC function, but same results (register that corresponds to ADCINA0 always has 4095). 

    I'm beginning to think there may be a hardware issue, which is strange because I checked the input pin for ADCINA0, and I see a value of about 1.65V, not 3.3V. 

    Any other ideas as to what might be happening?

    Best,

    Matthew

  • 0 in reply to Matthew Krenik
    TI__Guru 62975 points

    Matthew,

    Which package type are you using?  80-pin or 100-pin?

    Are you using internal reference mode?

    -Tommy

  • 0 in reply to tlee
    Intellectual 675 points

    Hello Tommy, I'm using the 100-pin package. And I'm using internal reference mode (VREFLO = Gnd, VREFHI = VdADC33). 

  • 0 in reply to Matthew Krenik
    TI__Guru 62975 points

    Matthew,

    Are you seeing this on multiple PCBs?  I wonder if there might be an internal short between ADCINA0 and VREFHI.

    Are you sampling the 1.65V signal through a configurable connection like a wire?  It would be interesting to include a series resistor like 10kOhm between ADCINA0 and the 1.65V signal.  A voltage drop across the resistor when the ADC is idle would suggest that there is an unexpected leakage path on ADCINA0.

    -Tommy

  • 0 in reply to tlee
    Intellectual 675 points
    Hey Tommy, sorry for such a delay in the response. I was finally able to get going on this project again.

    I connected a 10kOhm resistor between ADCINA0 and the 1.65V signal. There was no voltage drop across the resistor. This suggests the C2000 is fine, so the issue must be in software, correct? What kind of things should I look for? It seems like when I force the SOCs manually, I should get a ADC reading from the pin... which has not been the case.
  • 0 in reply to Matthew Krenik
    TI__Genius 11951 points
    Matthew,
    I think the first order is to determine whether we are dealing with a hardware, silicon, or software issue. I would begin by running the unmodified adc_soc example from controlSUITE. If this gives expected ADC results then we have narrowed the issue to SW, otherwise we should continue to use adc_soc as known good SW but start to look at the HW and silicon.

    In his last post, Tommy asked whether you are observing this behavior on multiple PCBs. If so then it might point to a HW issue unless the devices are being damaged in the process of mounting them to the PCB, for example from electrical over-stress (EOS). If you have multiple PCBs but only one is showing an issue, the silicon for that PCB might be damaged. I presume you have only one PCB and only one F28069 device? BTW is it a TMS device (should be clearly marked on the top surface)?

    If we assume the silicon is not damaged, and that we are looking at a HW issue, the main culprits would be the analog power, grounds, and reference pins. I would ohm the connections of pin-26 (VSSA) and pin-27 (VREFLO) and make sure they are connected to ground and measure to make sure that pin-25 (VDDA) is getting ~3.3V. You also indicated that pin-24 (VREFHI) is tied to VDDA so it should have 3.3V as well, though this is not required for internal reference mode. You could also try running with external reference mode since you have VREFHI connected to 3.3V just to give another data point.

    If the HW and SW checks out, it may that your device has been damaged and will likely need to be replaced.

    Regards,
    Joe
  • 0 in reply to Joe Prushing
    Intellectual 675 points
    Hey Joe, Thanks for the feedback. I will run adc-soc when i get back in the lab. To answer your questions, I have 2 PCBs and 2 C2000s that use the same design for this part of the circuit (though they aren't the same boards). Both have the same issue only on ADCINA0, but the other channels work fine. Yes, the C2000 I have is marked TMS. I will check the analog poewr, grounds and reference pins.

    Best,
    Matt
  • 0 in reply to Matthew Krenik
    TI__Genius 11951 points

    OK Matthew, I see I missed that one point in your original post.  I still think using adc_soc is the right choice to rule out the software, but generally if there was a problem with the supplies or references it should affect all channels.  It looks like I've finally caught up to where Tommy was going with his debug :)  His resister check should've caught a short in the device or PCB, but can you ohm out the connection between pins 23 and 24? 

  • 0 in reply to Matthew Krenik
    Guru 13185 points
    Hello Matt,
    I don't really follow the history, but seems that this is in Errata documentation www.ti.com/.../sprz342h.pdf page 12.
    Hope this is the issue.

    Best regards,
    Maria