• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 84 subscribers
  • Views 450 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28377D: ADC - Errorneous SOC acquisition

Clément Letonnelier
Expert 2816 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: C2000WARE

Hi,

I have configured the 16 SOC of one of the ADC to alternatively convert VREFLO and ADCIN14 channel which is around half the full scale.

I trigger the 16 SOCs at once by writing to the SOC force trigger register.

However, when I read the 16 results, they all seem to have acquired ADCIN14.

If I run the 16 SOC on ADCIN14 (resp. VREFLO), it acquires correctly, though if the previous acquisitions were done on VREFLO (resp. ADCIN14), the first acquired SOC is equal to VREFLO (resp. ADCIN14) instead of ADCIN14 (resp. VREFLO).

Is there a bug here ?

Didn't see anything about that in the errata sheet.

Clément

  • 0
    TI__Expert 3720 points
    Hi Clément,

    Can you share the configuration of ADC you are using for alternative source conversion from VREFLO and ADCIN14.

    Thanks
    Himanshu
  • 0 in reply to Himanshu Chaudhary60
    Expert 2816 points
    Hi,

    What would you like ? Code source ? Registers value ?

    Clément
  • 0 in reply to Clément Letonnelier
    TI__Expert 3720 points
    Hi,

    You could probably provide snippet of the ADC configuration you are using.

    Thanks
  • 0 in reply to Himanshu Chaudhary60
    Expert 2816 points

    Hello,

    Find attached the export of the registers value after initialization:

    /cfs-file/__key/communityserver-discussions-components-files/171/ADC_5F00_registers.xlsx

    The only thing we do after that is to force the 16 triggers by writing 0xFFFF in the appropriate register, wait for the SOC acquisition and read the results.

    I am supposed to get 0 on the SOC which acquires ADCIN8 and around 1900 on the SOC which acquires ADCIN13 (our external 3V ref divided by 2).

    However for all the SOC results we read the value of ADCIN13.

    Clément

  • 0 in reply to Clément Letonnelier
    Expert 2816 points

    Hi,

    Any update on this ?

    We have also experienced cases where the first SOC result is incorrect and the following are ok.

    This is quite critical, unless we made a code mistake, the behavior is highly erratic.

    Looking forward to your answer,

    Best Regards

    Clément

  • 0 in reply to Clément Letonnelier
    Expert 2816 points
    Hi,

    Two days since I attached the extract of the registers that was asked to me and on answer.

    Our project is stuck due to this issue as the behavior is erratic.

    I hope it's just an error of SW but so far can't confirm without TI help.

    Best regards,
    Clément
  • 0 in reply to Clément Letonnelier
    TI__Guru 60865 points
    Hi Clement,

    Based on your ADC configuration memory dump, ADCCTL2 = 0x0000. This would indicate that the PRESCALE field = 0, which results in ADCCLK = SYSCLK. If you are running the CPU at 200MHz this will be much too fast for the ADC to operate correctly (the max ADCCLK is 50MHz). Typically this field would be 6 => ADCCLK = SYSCLK/4.

    If you are sampling all 16 SOCs, I'd typically expect that ADCINTSEL1N2.INT1SEL = 15 and INT1EN = 1. Even if you don't take the ISR, you can use the ADCINT1 flag to determine that all the conversions are complete. (You might also want to set late interrupt mode to ensure the int flag isn't set until the last conversion result latches vs. first conversion S+H has ended in early interrupt mode)

    A good strategy for exploring the ADC configurations to see if things seem right is to add "AdcaRegs" (or whatever ADC module you are working on) to the expressions window and then expand the register set and then various registers and fields to explore the configurations. You can then compare what is programmed vs. the bit descriptions in the TRM. Do this at some point after all the ADC initializations have run.
  • 0 in reply to Devin Cottier
    Expert 2816 points
    Hi Devin,

    Mea culpa, I should have checked that the registers were at our expected configuration and obviously as you pointed it was not the case.

    I had done a copy-paste of the code of one of the Adc*Regs and didn't change the *... Leading to one ADC correctly set and not the others.

    Thanks for pointing out.

    So basically what you state is that monitoring ADCBSY is not the right solution to check for end of conversion if I force all the SOC at once ?

    Clément
  • 0 in reply to Clément Letonnelier
    TI__Guru 60865 points
    Hi Clement,

    I'd recommend you use the ADCINT flag for this purpose and you'll see that all TI examples use this method.

    I'm not sure off-hand if the ADCBSY will be continually set if you have back-to-back conversions or if it will toggle back and forth between on/off as the ADC switches between converting/sampling. The description makes me think that it'll toggle back-and-forth.

    Definitely check out the ADC examples in C2000ware if you haven't already.
  • 0 in reply to Devin Cottier
    Expert 2816 points
    Thanks for the clarifications.

    I had checked them some time ago but will definitely get a new eye on it.

    Clément