• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 667 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28075: ADC Interrupt Time Definition

David DeBaun
Intellectual 405 points
Part Number: TMS320F28075


Hello,

I have a question about the timing of the tINT parameter defined in SPRS902G Datasheet for TMS320F28075. From Table 5-49, the tINT(LATE) column parameter values in SYSCLK cycles match those in the tEOC column. However, from the definition in Table 5-48, tINT(LATE) appears to be when INTPULSEPOS bit is set, so it should coincide with when the conversion result is latched into the result register, which would be tLAT from Table 5-49, not tEOC, which occurs earlier when the conversion result is not yet latched in the result register.

Basically, I would expect the values in the tINT(LATE) column in Table 5-49 to match those in the tLAT column instead of those in the tEOC column. However, since they are numerically less than those in the tLAT column, it seems like we are not guaranteed that the conversion result is latched into the result register when the interrupt flag is set. Is this correct, and do we need to safeguard against obtaining a previous result, which would make this mode no more convenient that if INTPULSEPOS were 0 and we interrupted after tINT(EARLY)?

Please advise.

Thank you,

EE

  • 0
    TI__Guru 60865 points
    Hi EE,

    I'm looking into this to confirm the timings and see if it is possible to read the old result.

    In the case that you trigger an ISR from the interrupt flag, the context switch time is sufficiently long that you will always read the updated result.

    Where it would potentially be an issue is if you spin-wait on the ISR flag, then immediately read the result. I don't think there are any branch instructions that takes less than 2 cycles, so maybe if the subsequent read instruction happens immediately in the next cycle there could be an issue. I think worst case here you'd need to insert 2-3 NOP instructions after the spin-wait.

    If you have multiple results and you spin-wait on the ISR flag of the last result, then start reading from the beginning of the sequence it should also be OK.
  • 0 in reply to Devin Cottier
    Intellectual 405 points
    Hi Devin,

    Thank you for your response, the information, and for looking into it further. I also was just noticing that in the TRM SPRUHM9D Table 9-8 appears to have some similar information but in this case the tINT(LATE) column matches the tLAT column instead of the tEOC column. This looks more like what I was expecting, but I was wondering why this would be different from the datasheet?

    Thanks,

    EE
  • 0 in reply to David DeBaun
    Intellectual 405 points
    One additional question is whether using the ADC interrupt to kick off a DMA burst could result in previous value being moved instead of the new one.
  • 0 in reply to David DeBaun
    TI__Guru 60865 points
    Hi EE,

    Yes, we see the discrepancy in the documentation (these should match) and we'll make sure we look a the timings w.r.t. DMA burst in the investigation.
  • 0 in reply to Devin Cottier
    TI__Guru 60865 points
    Hi EE,

    We are still working on this.
  • 0 in reply to Devin Cottier
    TI__Guru 60865 points
    Hi David,

    Sorry for the delay. We are still investigating this; things got a bit delayed by various engineers' holiday vacations.
  • 0 in reply to Devin Cottier
    TI__Guru 60865 points

    Hi EE,

    We are working on an erratum for this issue.  Testing has determined the following:

    • Spin-waiting on the ADCINTFLG, then reading the ADCRESULT:
      • Based on the available ways the spin-wait loop can be generated by the compiler, there should be no way to read the old values regardless of resolution or PRESCALE setting.
    • Reading the ADCINTFLG, then immediately reading the ADCRESULT:
      • If the delta between tEOC and tLAT is less than 3 cycles, then the read ADCRESULT will always be new if ADCINTFLG read-back as '1'. 
      • NOPs should be manually inserted between the ADCINTFLG read and the ADCRESULT read if the delta is >= 3 cycles in the timing table if this method is used
    • DMA triggered from ADCINTFLG
      • The DMA could read the old results in this case.  The easiest workaround is to setup two DMA channels, both triggered by ADCINTFLG.  The DMA latencies are such that the second read will always be of the updated ADCRESULT value.  

  • 0 in reply to Devin Cottier
    TI__Guru 60865 points

    Sorry, one more clarification on the specific cases where the DMA workaround is necessary:

    • DMA will read the ADC result 3 SYSCLK cycles after the ADCINTFLG is set, so no workaround should be necessary for 16-bit mode or 12-bit mode with SYSCLK/ADCCLK divider of /4.5 or less.