TMS320F28379D: F2837xD Delfino ADC

Thanks Devin,

I had stated all SOCs were triggered by timer0 and nothing else, in which case the SOC number does have some priority (order), right? If I use SOC0 for the first pair Va/Ia, SOC1 for Vb/Ib and SOC2 for Vc/Ic, would that work in that order (again only single source trigger Timer0)?

Sorry I forgot to mention ADCA is used for something else (DACA, DACB and some other 12-bit signals) so we don't have that. The B14/B15 solution sounds interesting. I will look into that. This has been a very good exercise on the ADC. Thanks for your help!

Yes, I've been consulting the TRM for a bit and found it can be quite confusing at times, like the mention of SOCC and SOCD that might be a typo.

We intend to use ADCA at 12 bit independently and asynchronously from the other 3 modules (16 bit), probably with another trigger source. This is to read other sensors aside from the 3 phase Vs and Is. Some channels on ADCA might be software SOC force type as well. The TRM states that mixing the resolutions might result in asynchronous operation but on the ADCA that is what we might intend to do for all channels. Do you see any downsides to this setup?

Hi Devin,

By bad did you mean out of phase bad or actual signal distortion? Do the ADC modules run totally independently from each other with different trigger sources, especially when overlapping might occur? I had actually considered the solution you suggested (changing resolution on the fly) but thought I wouldn't need it if I dedicated a whole module with a separate trigger for these 12 bit purposes. Distortion might be a deal breaker but out of sync is not a problem for our intended usage.

Hi ED,

The performance will degrade.  For 16-bit, the performance degradation is pretty bad, so we don't suggest/support this mode.  For 12-bit, we specify what the performance degradation will be for ENOB and ADC-to-ADC isolation (basically internal ADC-to-ADC cross-talk):

You can read more about what does/doesn't qualify as asynchronous in the TRM in the section titled "Ensuring Synchronous Operation", but the short description is that you want to operate all the ADCs in lock-step...so for a given ADC use the same resolution and signal mode configurations and for each SOC use the same trigger sources and same S+H duration (different channel selects are OK).  

There is no waiting time required between changing the ADC resolution and sampling again.  The preferred way to do this is by using the ADC setMode function.  If this takes too long, you can also just flip the bits for resolution and signal mode...in this case use the function to set the mode to 16-bit to load the correct trims...there will be a slight performance degradation in 12-bit mode due to not loading 12-bit specific trims, but this is not a significant performance hit. 

Glad to have this discussion. We would overlook the ADC cross talk otherwise. Though I could see this to be a significant source of bugs for a more demanding and complex sampling scheme where a mixture of 12-bit and 16-bit conversions is required. For us we would just flip the bits in the ISRs and be done with it. I would assume doing it for each of the 4 modules every time an ADC ISR is done, like:

In 16-bit ISR

interrupt void ADCB1_ISR(void)                                   // 16-bit ADC

{

PieCtrlRegs.PIEACK.all = PIEACK_GROUP1; // Must acknowledge the PIE group

.......

.......

// Change to 12 bit res

AdcSetMode(ADC_ADCA, ADC_RESOLUTION_12BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCB, ADC_RESOLUTION_12BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCC, ADC_RESOLUTION_12BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCD, ADC_RESOLUTION_12BIT, ADC_SIGNALMODE_SINGLE);

}

and in 12-bit ADC ISR

interrupt void ADCA1_ISR(void)                                   // 12-bit ADC

{

PieCtrlRegs.PIEACK.all = PIEACK_GROUP1; // Must acknowledge the PIE group

.......

.......

// Change to 16 bit res

AdcSetMode(ADC_ADCA, ADC_RESOLUTION_16BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCB, ADC_RESOLUTION_16BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCC, ADC_RESOLUTION_16BIT, ADC_SIGNALMODE_SINGLE);
AdcSetMode(ADC_ADCD, ADC_RESOLUTION_16BIT, ADC_SIGNALMODE_SINGLE);

}

Hi Devin,

Was thinking a bit about this scheme... What happens if sampling one of the resolutions is a lot faster than the other, i.e. NOT interleaving (or what you may have referred to as LOCKSTEPPING?)? Let's say the faster 16-bit samples are read in the ISR, then resolution is changed to 12-bit, but the next conversion is still 16-bit before a slower 12-bit sampling is triggered. Would that create a problem for the 16-bit samples being read as 12-bit?

This is not good news at all. Like I said we intend to use the 12-bit module ADCA completely independently of the other 3 16-bit modules, which can mean random sampling as well. Per your explanation it is not possible this way. There must be some kind of lockstep or interleaving relationship between ALL the modules for the mixing of resolutions to work properly. If it's true it could be a major weakness of the ADC feature!