TMS320F28379D: ADC voltage reference problem

Hi Andre,

In general you shouldn't have to worry about manually calibrating the ADC on this device.  The boot ROM will move most of the trims from OTP (factory calibration values) to the ADC (HW calibration registers) and the SetMode() function will move the rest based on the mode you've selected.

Are you operating the ADC in 12-bit single-ended mode, or in 16-bit differential mode?  If in differential, are you sure the common mode voltage is correct for your signal?

A specific older version of the launchpad does have an erratum where an ADC input channel may be shorted to VREF.  Please confirm if this applies?: https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/581950

What is the source for the 0 to 3.3V on ADCIN14?  There really shouldn't be any effect on all the other channels as long as the value is below VDDA (3.3V).  Is it possible the input has been damaged by ESD or EOS?  You might check the leakage on the pin, it should be well under 2uA.  You could also just use a DMM to confirm that the forced voltage is what you actually see on the pin.   

Good Morning,

I am not using the SetMode () function in my code, I set the registers manually. Does this influence in any way?

I am using 12 bit single (single) end mode.

My LaunchPad is F28379D version 2.0, it does not apply to version 1.0 of the link you sent.

The value between 0V and 3.3V applied to the ADCIN14 input comes from the LaunchPad card itself. The value of 3.3V was not exceeded. No occurrence of ESD or EOS occurred.

LaunchPad was never connected to any external circuit, it was not a malfunction. As soon as I tried to verify the functioning of the ADCs they already failed.

As suggested, I checked the voltage and current at input ADCINA2 for example. During the test the ADCINA2 input was connected to LaunchPad pin 3.3V and thus maintained throughout the test. The following was observed: When the ADCIN14 input was connected to the GND, the voltage and current on the ADCINA2 pin were 3.24V and 11.5uA respectively. When the ADCIN14 input was connected to 3.3V, the voltage and current on pin ADCINA2 were 3.24V and 1uA respectively. When input ADCIN14 was not connected to any potential (fluctuating) voltage and current on pin ADCINA2 were 3.24V and 8.5uA respectively.

Is there an email or platform on which I can send the code that is being used in the project for analysis? As well as some waveform images obtained from reading each of the ADCs by IDE CCS 'own Graph tool?

Hi Andre,

Using the SetMode() function will ensure the best trims are loaded for the specific mode you are using.  I doubt this is contributing to the issue you are observing, as the performance difference will be subtle.

Do you observe the 8uA+ pin currents when the ADC is actively sampling, or when the ADC is idle?  If the ADC is idle and this is static pin leakage this would strongly indicate the pin has been damages as the max pin leakage per the datasheet is 2uA (and this should not be observed except for units at the process extremes when exposed to temperatures near the operating limits). If the ADC is actively and periodically sampling, you will get some additional average current draw proportional to the sample rate.

You can post the relevant code snippets (not the full project or C code) and waveforms here on the e2e.     

Are you sure the ADC VREFHI voltage generation circuits are working as expected?  You might DMM probe the 5V rail that is supplying U13, U11, and U19.  If you have a microscope and a fine DMM probe tip, you might also try directly probing the output pin (pin 6) of U11 and U19 to ensure the VREFHI voltage is as expected (very close to exactly 3.000V).  

I tested the stress on ICs U11, U13 and U19. All are powered with 5V and generating 3V on their output pins. There seems to be no problem with these reference generator circuits, even because the PWMs modules are working perfectly. The whole problem seems to be related to the ADCIN14 pin because it is the only one that influences the measurement of ADCs on the other input pins. Just changing the voltage on the ADCIN14 pin even though it is configured as an input changes the current and consequently the reading on the other analog inputs. Unfortunately with the past you still can not solve my problem. My LaunchPad seems to have come defective as it is not error in the code, I tested the code on a friend's board worked perfectly. The problem is physical in hardware and seems to have already been shipped like this. What to do?

Hi Andre,

Did you order your LaunchPad from TI? If so you can contact support at the link below:

http://www.ti.com/guidedsupport/call-ti-support

Please reference this E2E post in doing so.

Best,

Kevin

I could not change the launchpad, Texas support said it did not provide warranty for these cases. So is the consumer harmed?

Hi Andre,

Sorry for the delay in response & we're sorry for the trouble you're facing here.

Based on your description in the above thread, TI agrees that you should be offered a replacement.

You should then go to whomever you bought the EVM from & ask for a replacement kit.  In your request, you should refer to this E2E thread & this post - which should expedite the process.


Thank you,
Brett

Good night,

But I bought the EVM directly from the Texas Instruments website, ie it was not from any vendor. In this case how to request replacement of EVM? Since, as reported in the E2E forum, it was apparently a manufacturing defect?

André

Hi Andre,

At the link Kevin shared, can you scroll to the bottom and click, 'Contact TI Customer Support Center'. Then create a new case of type TI Store Order Issue.

In the form to fill out, for part number make sure to choose the EVM part number that you ordered.  And in the text, request a replacement (note that TI will not offer a refund) EVM from TI & provide a URL to this thread.

Hopefully this helps!


Thank you,
Brett