TMx320F28377D sparkle codes

Hi Tjarco,

Sparkle codes are caused when a comparator in the ADC doesn't settle to a voltage level that can be resolved as a digital 1 or 0 in the allotted time (metastability). This signal then gets latched as a different digital value in different places, causing some of the ADC bits to be in error. This looks like a large random error for a single ADC conversion. This error is typically in the 20-200 LSB range and can be positive or negative.

Hi Devin,

Thank you for your valuable reply. Is this effect present on every ADC on every Silicon Rev0 & RevA in every configuration over the full temperature operating range..etc?

Or is it depending on the silicon batch, that one batch has more "sparkle codes" than another silicon batch? Or that one ADC on the die has more a lot of sparkle codes and another ADC on the same die has none?

My problem: I have a TMX320F28377D Rev.A on a development kit (card & docking) and when I have this setup to control a converter the result is stable (within specs). When I have a 'custom' board with the same cpu, Rev.A but another batch nr, then I see random 'distortion' of the controller process. I see the controller 'respond' on some 'step'  but I can't explain this. Could be a (crucial) difference in board design but I have my doubts. The setup using the dev kit was very 'breadboard' with poor grounding, etc.

Best regards,

Tjarco

PS: Is it correct that the ADC-calibration/trim is a internal temperature compensation (meta-stability of the SAR logic)? When I cooling down the DSP below 40Celcius the "sparkle codes" seem to disappear. If I heat the DSP to >50Celcius the "sparkle codes" come back and increase when increasing the temperature.

Hi Tjarco,

Do you still see the issue after you apply the workaround in the errata (write 0x7000 to some registers)?

What is your effective sample rate, and roughly how often do you see the 'step' (once a second, once a minute, once an hour, ...etc)?

The metastability is essentially related to the "speed" of the comparators. Increasing the temperature, reducing the supply voltage, or having "slow" material is expected to slow down the comparators, potentially aggravating the issue. Reducing the ADCCLK may help.

Hi Devin,

Thank you for your reply.

Yes, I also experience this effect with written 0x7000 to the registers (with EALLOW). When heating up, the effect is frequently visible, with an interval of seconds (large steps) and it sputters with a frequency of some miliseconds (smaller steps). The sample rate is ~1MSPS and has "oversampling" by burst sampling ADCB3 and ADCB2 multiple times in 16bit differential mode. I see know that the prescaler is set to 50MHz, and the workarround suggests <=40MHz. So I'll try that first. I also experience that the first conversion is ~30dec code lower that the following conversions in a burst-mode conversion cycle. I suppose this is because of the (unused) SOCCTL 0 to 5, which are set to odd number 3? I'll make these 2, just in case.

                  AdcbRegs.ADCCTL2.bit.PRESCALE=6;    //200MHZ core, prescale on 4 -> 50MHz, should be <= 40MHz according to errata

        AdcbRegs.ADCBURSTCTL.bit.BURSTEN = 1; //Enable ADC burst mode
        AdcbRegs.ADCBURSTCTL.bit.BURSTTRIGSEL = ePWM1_ADCSOC_AC; //CPU1 Timer 2 will trigger burst of conversions
        AdcbRegs.ADCBURSTCTL.bit.BURSTSIZE = 10-1; //conversion bursts are 10 conversions long
        AdcbRegs.ADCSOCPRICTL.bit.SOCPRIORITY=6;    //15-AdcbRegs.ADCBURSTCTL.bit.BURSTSIZE=6


        AdcbRegs.ADCSOC0CTL.bit.CHSEL  = 3;  //SOC will convert on channel
        AdcbRegs.ADCSOC1CTL.bit.CHSEL  = 3;  //SOC will convert on channel
        AdcbRegs.ADCSOC2CTL.bit.CHSEL  = 3;  //SOC will convert on channel
        AdcbRegs.ADCSOC3CTL.bit.CHSEL  = 3;  //SOC will convert on channel
        AdcbRegs.ADCSOC4CTL.bit.CHSEL  = 3;  //SOC will convert on 3
        AdcbRegs.ADCSOC5CTL.bit.CHSEL  = 3;  //SOC will convert on 3
        AdcbRegs.ADCSOC6CTL.bit.CHSEL  = 0;  //SOC will convert on 3
        AdcbRegs.ADCSOC7CTL.bit.CHSEL  = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC8CTL.bit.CHSEL  = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC9CTL.bit.CHSEL  = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC10CTL.bit.CHSEL = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC11CTL.bit.CHSEL = 4;  //SOC will convert on 3
        AdcbRegs.ADCSOC12CTL.bit.CHSEL = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC13CTL.bit.CHSEL = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC14CTL.bit.CHSEL = 2;  //SOC will convert on 3
        AdcbRegs.ADCSOC15CTL.bit.CHSEL = 2;  //SOC will convert on

        AdcbRegs.rsvd5[3] = 0x7000;    //Silicon 0 and A: Reduce sparkle codes...

Hi All,

I keep seeing some jitter in my controller and it's seems to be very random (upto ~10 decimal codes).
My question: How often occur these 'sparkle codes' on an ADC conversion? is this once in 10 conversions or once in 100 conversions...
Can this be quantified?

VSS is for analog subsystem separated from other integrated modules in rev B, how (much) will this improve my conversion results when using a 3V reference in 16bit mode? Can this be quantified?

Best regards,

Tjarco

Hi Tjarco,

Typically we quantify sparkle codes as > 20 codes or so. If you are seeing error of about 10 codes, and it is very frequent, I suspect this is probably noise coupling in from somewhere (you could take an FFT of a sequence of conversion results to attempt to determine the frequency of the source, which may give some hints as to where it is coming from).

Are you running multiple ADCs asynchronously? This was one of the motivators of separating the ADC VREFLO from VSSA: to prevent the ADCs from influencing each other.