28035 SOC problems

Hi Matt,

How are you checking where the SOC is being placed relative to your PWM?  Do you have the SOC being output to a pin (via ADCSOCAO or ADCSOCBO perhaps)?  If not, I would recommend doing this to confirm your understanding and it will allow us to better debug the issue.

The other thing I might recommend is to confirm that the SOCxSEL value is being set as you expect by viewing in the watch window via CCS in real-time mode.

I can confirm that SOCxSEL = 2 should generate an SOC on a PRD event.


Thank you,
Brett

Hi Brett,

Thanks for your response!

I have an ADC_isr that runs when the A/D conversion is finished.  I was toggling a GPIO pin in the ISR to determine the approximate placement of the SOC.  I realize that the ISR won't trigger until the A/D conversion is complete, but was accounting for that delay by computing the expected A/D conversion time and accounting for that in my measurement.

Having said that, I tried your suggestion of outputting SOC to a pin.  This method shows the SOC doing exactly what it should - thanks for the suggestion.

Based on toggling a GPIO in the ISR, it looks like the ISR is triggering 3.94 usec after the SOC.   Perhaps I'm computing the conversion time incorrectly.   I'm using a mix of single and simultaneous conversions, with a SYSCLK of 60 MHz and an ACQPS of 6 for each conversion.  I expect each sample and hold to take ((6+1)/60e6) = 116.7 nSec.  Each conversion takes 13 cycles or 13/60e6 = 216.7 nSec.  So a single total acquisition and conversion will take (116.6 + 216.7 = 333.4 nSec and each simultaneous scq and conversion will take (116.7 + 216.7 + 216.7) = 550 nSec.

I've configured the ADC to generate EOC (and hence start the ADC ISR) after SOC8 conversion is complete.  That's after 2 single conversions and 3 simultaneous conversions, so the total time from SOC to EOC should be (333.4 * 2) + (550 * 3) = 2.316 uSec.  But the time measured on the scope is 3.94 uSec.  Can you help me account for this discrepancy?

The ADC config code is below.

Thanks for your help!

--Matt

ADC Setup Code

AdcRegs.ADCSAMPLEMODE.bit.SIMULEN0 = 0U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN2 = 1U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN4 = 1U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN6 = 1U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN8 = 0U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN10 = 1U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN12 = 0U;
AdcRegs.ADCSAMPLEMODE.bit.SIMULEN14 = 1U;

AdcRegs.ADCCTL1.bit.INTPULSEPOS = 1U;
AdcRegs.INTSEL1N2.bit.INT1E = 1U;
AdcRegs.INTSEL1N2.bit.INT1CONT = 0U;
AdcRegs.INTSEL1N2.bit.INT1SEL = 8U;

AdcRegs.ADCSOC0CTL.bit.CHSEL = 2U;
AdcRegs.ADCSOC0CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC0CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC2CTL.bit.CHSEL = 7U;
AdcRegs.ADCSOC2CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC2CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC4CTL.bit.CHSEL = 4U;
AdcRegs.ADCSOC4CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC4CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC6CTL.bit.CHSEL = 6U;
AdcRegs.ADCSOC6CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC6CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC8CTL.bit.CHSEL = 1U;
AdcRegs.ADCSOC8CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC8CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC10CTL.bit.CHSEL = 3U;
AdcRegs.ADCSOC10CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC10CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC12CTL.bit.CHSEL = 2U;
AdcRegs.ADCSOC12CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC12CTL.bit.ACQPS = 6U;

AdcRegs.ADCSOC14CTL.bit.CHSEL = 0U;
AdcRegs.ADCSOC14CTL.bit.TRIGSEL = ADC_SOCA_TRIGSEL;
AdcRegs.ADCSOC14CTL.bit.ACQPS = 6U;

Matt,

So based on 60MHz execution time it looks like you're missing 96 cycles.

I know where at least some of the missing cycles are, but some may take more digging.

Good references:
http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000
http://www.ti.com/lit/spru430

1) Internal interrupt to ISR delay: minimum 14 cycles.  Variability between 14 and 16 cycles is common.
2) Context save: a full automatic C-interrupt save is 8 cycles
3) Since you say that you are doing a GPIO toggle, doing this will take some time as well: 4 cycles
(it's safest to look at the dis-assembly though; the context save and toggle should show up in the dis-assembly)
4) Is your ISR running from wait-stated memory like FLASH?  This will add extra time, often significant time.
5) Can you confirm that your CPU is running at 60MHz?


Thank you,
Brett

Matt,
The other thing to perhaps look at is any latency/jitter generated by an OS (if one is used).

Thank you,
Brett

Thanks,  Brett. 

I can confirm that we are running the ISR from internal RAM and that our system clock is 60 MHz.  

Also we are using DSP BIOS.   Do you have documentation that specifies the interrupt latency introduced by DSP BIOS?

Matt,

I think a fair amount of what you're seeing is attributable to your OS.

I don't work with many BIOS applications, but according to the following appnote you should expect ~88 cycles as your worst case interrupt latency when using a HWI (table 5) with things decently optimized. According to a colleague some of this latency may appear as jitter rather than a fixed delay.
http://www.ti.com/lit/spraax9

Hopefully this explains some of what you are seeing.


Thank you,
Brett