• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 801 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.

TMS320F28035: The refresh of ADC Convert Result

Tobby Guo
Intellectual 770 points
Part Number: TMS320F28035

#pragma CODE_SECTION(dcdc_isr, "IsrRamfuncs");

interrupt void dcdc_isr()

{

………

………

………

    IsrVars.u16_FSBB_CurrASampSum += adValueBranchACurr;

    IsrVars.u16_FSBB_CurrASampSum -= IsrVars.u16_FSBB_CurrASampAD[IsrVars.u16_FSBB_IsrTimer];

    IsrVars.u16_FSBB_CurrASampAD[IsrVars.u16_FSBB_IsrTimer] = adValueBranchACurr;

………

………

………

}

 

#pragma CODE_SECTION(Ocp_tzint_isr, "IsrRamfuncs");

interrupt void Ocp_tzint_isr(void)

{       

………

………

………

}

 

Add information

 

#define adValueBranchACurr               AdcMirror.ADCRESULT2

 

PieVectTable.EPWM5_INT = &dcdc_isr;        //Loop Calculate 

PieVectTable.EPWM6_TZINT = &Ocp_tzint_isr;

EPwm5Regs.TBPRD = EPWM5_TIMER_TBPRD;//299

EPwm5Regs.ETSEL.bit.SOCASEL = ET_CTR_PRDZERO; 

Phenomena

Only EPWM5 trigger interrupt void dcdc_isr(), the value of adValueBranchACurr stay the same when the code execute. when tirgger interrupt void Ocp_tzint_isr(void), the value of adValueBranchACurr different occasional when the code execute. We thought the AdcMirror.ADCRESULT2 refresh, we check the time as below:

 

the sampling is in the third channel. In theory, the max conversion time is 3*333ns=999us. The earliest time this code to be executed is 3.2us under normal conditions, and the latest time to be executed is 4.6us.

In the figure above, point A is the time when the A-way current conversion is completed, point B is the earliest time code executed, point C is the latest time code executed. Accounting, there should be no possibility of refreshing conversion value in the code execute , but this phenomenon does exist when tirgger interrupt void Ocp_tzint_isr(void).

So we want to know why conversion value refreshing between point B and point C? thanks.

 

  • 0
    TI__Guru* 80220 points

    Tobby,

    Thanks for reaching out to us on the E2E.  

    I'd like to see if this is related to this post on E2E https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/805657  if so we can combine them to make sure we are consistent with our reply. Please let me know if we can combine threads in this case.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Intellectual 770 points
    Matthew

    Thanks four your reply.

    When know the value of adValueBranchACurr different occasional , I seek Brian for help first. Brian give some suggestions almost same as Tommy give.
    • ADC is triggered exactly at TBCTR=0 and TBCTR=PRD
    The only ADC trigger source for EPWM5, the configure code is :
    EPwm5Regs.ETSEL.bit.SOCASEL = ET_CTR_PRDZERO;

    • ADC conversion time from trigger to ADCRESULT latch is < 1us
    AdcRegs.ADCSOC2CTL.bit.TRIGSEL = EPWM5_ADCSOCA;
    AdcRegs.ADCSOC2CTL.bit.ACQPS = ADC_SHCLK;
    AdcRegs.ADCSOC2CTL.bit.CHSEL = BRANCHCURRA;
    #define ADC_SHCLK 0x8
    This ADC conversion is on the third channel ,the every conversion max time is (9+13)*sysclk = 350ns, so the complete of third conversion is about 1us

    • The ADCRESULT is read at 3us and 4us after trigger
    We read the max and min value EPwm5Regs.TBCTR before the code execute, and calculate the read time is between 3us and 4us.

    After seek Brian for help, wo do more test, only find when tirgger interrupt void Ocp_tzint_isr(void), the value of adValueBranchACurr different occasional. When no tirgger interrupt void Ocp_tzint_isr(void), the value of adValueBranchACurr keep the same.
    interrupt void dcdc_isr() is priority Ocp_tzint_isr(void), so we think tirgger Ocp_tzint_isr(void) would have no impact on dcdc_isr(), but this could lead the value of adValueBranchACurr different occasional.

    Any more suggestions, thanks.

    Best,
    Tobby
  • 0 in reply to Tobby Guo
    TI__Guru 62975 points
    Tobby,

    Can you confirm which PIE Vectors you are enabling for ADCINT and EPWM6_TZINT?

    Do you know how long the Ocp_tzint_isr() ISR takes to execute? There is no default support for interrupt nesting so a TZ event with a long ISR could potentially delay the execution of dcdc_isr() such that it overlaps with the next ADC conversion.

    Something that you can try is to save the EPWM TBCTR value when entering dcdc_isr() and halt execution (for example, with ESTOP0) when the two adValueBranchACurr reads return different values. You will then be able to see if the dcdc_isr() execution was delayed when you have different ADC RESULT values.

    Also, is AdcMirror.ADCRESULT2 mapped back to AdcResult.ADCRESULT2?

    -Tommy
  • 0 in reply to tlee
    TI__Guru* 80220 points

    Tobby,

    Wanted to check back and and see if you had resolved your issue or still needed assistance?   I'm going to mark TI thinks resolved, but if you need to you can reply back and it willl reopen the thread.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 770 points

    Sorry, As Dragon Boat Festival, I donot reply immediately.

  • 0 in reply to tlee
    Intellectual 770 points

    Tommy

    Thanks four your reply. 

    Can you confirm which PIE Vectors you are enabling for ADCINT and EPWM6_TZINT?

           PieCtrlRegs.PIEIER3.bit.INTx5 = EPWM5_INT_ENABLE;

           PieCtrlRegs.PIEIER2.bit.INTx6 = EPWM6_TZINT_ENABLE;

           EPwm5Regs.ETSEL.bit.INTEN = 1;

           EPwm5Regs.ETSEL.bit.INTSEL = ET_CTR_ZERO;

           EPwm6Regs.TZEINT.bit.OST = 1;

           ADC only trigger SOC, EPWM_INT is trigger by CTR equal ZERO.

     

    Do you know how long the Ocp_tzint_isr() ISR takes to execute?

           Epwn disable by hardware, Ocp_tzint_isr() only initial some variables, max time 0.8us

     

    There is no default support for interrupt nesting so a TZ event with a long ISR could potentially delay the execution of dcdc_isr() such that it overlaps with the next ADC conversion.

           In my opinion, void dcdc_isr() is priority Ocp_tzint_isr(void), so when dcdc_isr() is executed , the trigger of Ocp_tzint_isr(void) has no impact, Ocp_tzint_isr(void) executed after dcdc_isr() run out .  When Ocp_tzint_isr(void)  is executed , it war interrupted by dcdc_isr().Only when dcdc_isr() run out , Ocp_tzint_isr(void) executed sequelly.

     

    Something that you can try is to save the EPWM TBCTR value when entering dcdc_isr() and halt execution (for example, with ESTOP0) when the two adValueBranchACurr reads return different values. You will then be able to see if the dcdc_isr() execution was delayed when you have different ADC RESULT values.

           We record the value of EPWM5.TBCTR. The earliest time this code to be executed is 3.2us, and the latest time to be executed is 4.6us either the ADC RESULT values different or same.

     

    Also, is AdcMirror.ADCRESULT2 mapped back to AdcResult.ADCRESULT2?

           I think the AdcMirror and AdcResult is same except DMA read. We not use DMA, so I think they are same in project, and in project ADC_REGS have no AdcResult.

    Best,
    Tobby

  • 0 in reply to Tobby Guo
    TI__Guru 62975 points

    Tobby,

    AdcMirror is not a native register on F28035. I recommend investigating what is being accessed when reading the AdcMirror.ADCRESULTn variables.

    -Tommy

  • 0 in reply to tlee
    Intellectual 770 points

    Tommy

    Thanks four your suggestion.

    #pragma DATA_SECTION(AdcMirror,"AdcMirrorFile");

    volatile struct ADC_RESULT_MIRROR_REGS AdcMirror;

    AdcMirrorFile     : > ADC_MIRROR,  PAGE = 1

    ADC_MIRROR  : origin = 0x000B00, length = 0x000020     /* ADC Results register mirror */

    Tobby

  • 0 in reply to Tobby Guo
    TI__Expert 5310 points

    Hi Champs,

    This only seems like a coding habit of Mr.Guo's company which has been used in several different products.

    ADC_MIRROR equals the ADC_Result which has been widely used in TI examples, but should not be a mistake.

    If there is any other ideas of this question, please feel free to share your comments.

  • 0 in reply to Brian Wang0
    TI__Guru 62975 points

    The only other idea I can think of at the moment is to use GPIO profiling, using different GPIOs to represent different ISRs and states.

    Set a GPIO when entering an ISR and clear it when exiting.  Toggle another GPIO for each ADCRESULT read.  Set another GPIO when the ADCRESULT value is found to be different and use it as a trigger for an oscilloscope.  Then it will be possible to trace the events leading up to the unexpected ADCRESULT read.

    -Tommy

  • 0 in reply to tlee
    Intellectual 770 points

    I have ask Brian to recheck time calculate, ADC configure , EPWM configure, Interrupt configure to ensure my above information is right.

    We latch the first transfer result in variable and use this variable next calculate to avoid occasional difference.

    I invited Brian to my office do more test when he next trip to my compamy.

  • 0 in reply to Tobby Guo
    TI__Guru* 80220 points

    Tobby,

    Wanted to check in to see if there had been an update on the above concern from your side.

    Best,
    Matthew