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.

F2806x ADC initial conversion errata

Is it possible that the following workaround to this issue in the F2803x Errata will also work for the F2806x device?

Thanks,

Stuart

  • Hi Stuart,

    Using the /2 bit in the '03x family results in no error because the ADCCLK ends up being 30MHz (or less if the SYSCLK < 60MHz).  The '06x family uses the /2 by default to get an ADCCLK of 45MHz.  In this case, the error is limited to about 4 LSBs, per the '06x errata.  The ADC architecture is virtually identical between these devices, so if you run an '06x device at 30MHz or less I think you should get no measurable error.  I am pretty sure there is a /4 enable on the '06x devices, so you could run at 22.5MHz and presumably have no error. (Note that all of this assumes you have enabled the non-overlap mode.) 

  • Devin,

    Thank you for the quick response.  I have a few follow on questions specific to the product that we are working on:

    Calculating the timing of sampling all of the ADC channels we need to sample and we are bit tight running the ADC at 22.5MHz.

    1. If a SOC is triggered alone and there at least X time before and after any other SOC would trigger, is it still affected by the initial conversion errata?  My normal sampling interval is 25 microseconds for all samples, but I need to sample one of those channels at 12.5 microsecond intervals (synchronous with the PWM update).  So I am wondering if I have all ADC channels sample as a sequential set, and then have that additional individual channel sample occur by its own, is it affected by the initial conversion errata?  The errata isn’t clear if it is caused by the SOC triggering itself, or the fact that more than one sample & conversion is occurring at the same time or back to back.

    2. If the first SOC in a sequence has a very long sample time set along with the NONOVERLAP mode, is that a possible way to get past the initial conversion errata?  I’m finding the 13 ADC cycles for conversion is what is taking up most of the time in my calculations since the sample time is only 7 ADC clocks, so the only way to reduce the conversion time is to run the ADC at a faster frequency.

    Thanks,

    Stuart

  • Hi Stuart,

    This issue is for the first conversion from any trigger after the ADC has been idle for any amount of time. This means that it would affect single conversions widely spaced from other conversions.

    Setting the S+H of the first conversion to be maximum or very large unfortunately will not help.
  • Devin,

    If we were to mask off the bottom 2 or possibly 3 bits, would that consume the 4 LSB of error? Is the initial error constant or varying; continuous, regular or random impulse? Would it average out to 0 over time on a heavily filtered sample? We need to understand the nature of the error to know how easy it would be to mask it or filter it out. We have 3 ADC channels that are (relatively) very slow changing temperatures that don’t need anywhere near 12-bit resolution.

    Thanks,
  • Hi Stuart,

    My understanding is that the ADC is running through it's 13 ADCCLK cycle conversion sequence even when the ADC is "idle". When a trigger comes in, and after the voltage is sampled, the ADC immediately transitions to its initial state and goes through the 13 cycles of the conversion. Depending on where it was in its free-running 13 cycle loop, transitioning back to the start can introduce some error. Slowing down the clock gives this error more time to settle out in the first state so it isn't seen in the conversion. The non-overlap setting also alters the conversion process such that the error has more time to settle out. If your triggers are coming at time durations equal to some multiple of 13 ADCCLK cycles, you will either always see the issue or always not see the issue. If the triggers come in at some other frequency (this is usually the case) then the error shows up pseudo-randomly, in about 1 out of 13 conversions. There is a process variation to the magnitude, so most devices won't see any issue at 45MHz. For devices that do see the issue, when it occurs I believe the error will always be in the same direction (e.g. always positive).

    Based on the above, averaging could help, but may not completely eliminate the error.

    Yes, masking the bottom 3 bits would completely mask the error. I am pretty sure you would be better off just leaving the result as-is though, as masking guarantees quantization error, but the first sample issue is usually nothing and at worst 4 LSBs.