• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 123 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280049: ADC Value Handling

Christian Gienger
Intellectual 290 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

Hi there,

i am using ADC on F28004x to capture some analog values. Unfortunately, I run into trouble when doing the first read after starting up my device.
Please see the following - a bit simplified problematic code:

float32 adCapture( void )
{
  Uint16 buff_hi;
  Uint16 buff_lo;
  float32 ret_val;

  //start of conversion
  AdcaRegs.ADCSOCFRC1.all = 0x000CU; //set SOC flags for SOC2 and SOC3

  //wait for end of conversion
  while(AdcaRegs.ADCINTFLG.bit.ADCINT3 == 0U)
  {
  };

  // reset flag
  AdcaRegs.ADCINTFLGCLR.bit.ADCINT3 = 1U;

  //capture vals
  buff_hi = AdcaResultRegs.ADCRESULT2;
  buff_lo = AdcaResultRegs.ADCRESULT3;


  //Do some calculations
  ret_val = (CON_AD_FAC * ((float32)buff_hi - (float32)buff_lo));
  ret_val = ret_val / 4.7;

  return ret_val;
}

When I read the ADC results from the result regs to the temporary variables buff_hi and buff_low, I run into trouble because buff_lo seems to be 0. When I set a breakpoint on the first line of my calculations, I can definitely examine this: buff_lo is 0, but ADCRESULT3 is not equal 0!

Is it possible that we got some timing problem here? Maybe that ADCRESULT3 is not loaded yet when I want to fetch the value from this register?
My colleague has experienced a similar behavior using another ADC instance on F28004x, where it seemed like the End of conversion flag is set some time before the results are loaded to ADCRESULTx.
This seems always to depend on the timing behavior of the whole code!

Do you know about such a behavior or did some other customers report this behavior, too?
Can you suggest a workaround?

Best regards,

Chris

  • 0
    TI__Genius 10845 points

    Hi,

    Can you check if the result buffers are declared as volatile? Also, the end of coversion flag can be set before the conversion is ended if early interrupts are being configured. This is done to offset some of the delay experienced before reading the actual result. PFB the description from the device TRM.

    Thanks
    Vasudha

  • 0 in reply to Vasudha Bhadoria
    Intellectual 290 points

    Vasudha,

    thank you for your reply. I am using the result buffers defined in f28004x_adc.h in C2000ware. The variables themselves are not declared volatile, but the overlain struct ADC_RESULT_REGS is.
    I use the Early Interrupt on another ADC engine, but not on this one.
    I tested when using a 1us delay after recognizing the EOC flag - this resolves the problem.
    Maybe only some NOPs are needed - i will check. I also recognized that the behavior of this error is dependant on changes in code when i do not use a delay after detecting EOC. A change somewhere else in code can result in a correct or incorrect content of ADC Result register. This lets me think more stronger, that we got a timing issue here.

    Best regards, Chris

  • 0 in reply to Christian Gienger
    Intellectual 290 points

    I did some additional tests and measurements - around 20 NOPs are necessary. With the F28004x clocked with 100 MHz, this is a delay of around 200ns - not very nice, but handlable.
    Best regards, Chris