TMS320F28035: TMS320F28035

Rayna Wang

Hi Experts,

I want to ask a question about ADC sampling issue.

The below is the test phenomenon/ results:

1# As the below figure shown, the big input current spike often occurs when PFC system running, while the input voltage spike is small.

However, in the figure 2, ADC sampling of input voltage wave gain from CAN bus, is different with the wave in figure 1 gain from Oscilloscope.

Through the ADC sampling waves, the voltage sampling value is not right, which is too big than the value in Oscilloscope.

2# The current spike happened period is around 0.46s.

3# When change the ACQPS value from 6 to 8, and the spike disappears, however this situation just test once.

4# When add some codes in "ISR" or "for" loop, sometimes, there are spikes while sometimes there are not.

Customer wonder that:

1# Is the voltage incorrect sampling caused the current spike?

2# What caused the voltage incorrect sampling, is that just because the ACQPS value is too small?

3# Why add code in "ISR" or "for" loop, the spike phenomenon could disappear sometimes?

Thanks!

Fullscreen 2016_newOBC_Adc.c Download

/***********************************************************************************
 * FileName: 2016_newOBC_Adc.c
 *
 * ���ܣ�          AD���ã�AD���ݴ���
 *
 * ���÷�Χ��
 *
 * Created on: 2016��3��18��
 *
 * Author: Administrator
 ***********************************************************************************/

#include "2016_newOBC_main.h"    /*��������ͷ�ļ�*/

void AdcInit(void)
{
    InitAdc();
    EALLOW;
    // 1.���ò���ģʽΪ˳�����ģʽ,���Ϊ��һ����ģʽ
    AdcRegs.ADCSAMPLEMODE.all       = 0;

    // 2.ʹ���ڲ��¶ȴ�����
    AdcRegs.ADCCTL1.bit.TEMPCONV    = 1;

    // 3.����SOCx��Ӧ����ͨ��,[����]��궨��RESULT_XXX���Ӧ
    AdcRegs.ADCSOC0CTL.bit.CHSEL    = CH_PFC_IT2;  // ���ٵ����źŲ���,��PWM����
    AdcRegs.ADCSOC1CTL.bit.CHSEL    = CH_PFC_IT2;  // CH_PFC_IN_IAC;
    AdcRegs.ADCSOC2CTL.bit.CHSEL    = CH_PFC_IT2;  // CH_PFC_IN_IAC
    AdcRegs.ADCSOC3CTL.bit.CHSEL    = CH_PFC_IT1;  // CH_PFC_IN_IAC;
    AdcRegs.ADCSOC4CTL.bit.CHSEL    = CH_PFC_IT1;  // CH_PFC_IN_IAC;
    AdcRegs.ADCSOC5CTL.bit.CHSEL    = CH_VAC_L;     //result_5
    AdcRegs.ADCSOC6CTL.bit.CHSEL    = CH_PFC_VAC_L; //result_6
    AdcRegs.ADCSOC7CTL.bit.CHSEL    = CH_VAC_N;     //result_7
    AdcRegs.ADCSOC8CTL.bit.CHSEL    = CH_PFC_VAC_N; //result_8
    AdcRegs.ADCSOC9CTL.bit.CHSEL    = CH_VBULK;  // ����Ϊ�����źŲ���
    AdcRegs.ADCSOC10CTL.bit.CHSEL   = CH_VBULK;   //result_10
    AdcRegs.ADCSOC11CTL.bit.CHSEL   = CH_NTC_AMB;
    AdcRegs.ADCSOC12CTL.bit.CHSEL   = CH_NTC_LLC;
    AdcRegs.ADCSOC13CTL.bit.CHSEL 	= CH_LLC_DRV_UDC;//CH_PFC_IN_IAC;
    AdcRegs.ADCSOC14CTL.bit.CHSEL   = CH_LLC_DRV_UDC;
    AdcRegs.ADCSOC15CTL.bit.CHSEL   = CH_NTC_PFC;  //pfc�¶�

    // ����SOCx����Դ  //debug: ��Ҫ����ʵ��������е���
/*    AdcRegs.ADCSOC0CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //PFC����㴥��
    AdcRegs.ADCSOC1CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //IT1
    AdcRegs.ADCSOC2CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //IT1
    AdcRegs.ADCSOC3CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //IT2
    AdcRegs.ADCSOC4CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //IT2
    AdcRegs.ADCSOC5CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;
    AdcRegs.ADCSOC6CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;
    AdcRegs.ADCSOC7CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;
    AdcRegs.ADCSOC8CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;   //��LLC����pwm����
    AdcRegs.ADCSOC9CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;   //��LLC����pwm����
    AdcRegs.ADCSOC10CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;
    AdcRegs.ADCSOC11CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC12CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC13CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC14CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC15CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
*/

    AdcRegs.ADCSOC0CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //PFC����㴥��
    AdcRegs.ADCSOC1CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //IT2
    AdcRegs.ADCSOC2CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //IT2
    AdcRegs.ADCSOC3CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //IT1
    AdcRegs.ADCSOC4CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //IT1
    AdcRegs.ADCSOC5CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //VIN_L
    AdcRegs.ADCSOC6CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //VIN_L
    AdcRegs.ADCSOC7CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //VIN_N
    AdcRegs.ADCSOC8CTL.bit.TRIGSEL  = ADCTRIG_EPWM2_SOCA;  //VIN_N
    AdcRegs.ADCSOC9CTL.bit.TRIGSEL  = ADCTRIG_EPWM1_SOCA;  //��LLC����pwm����
    AdcRegs.ADCSOC10CTL.bit.TRIGSEL = ADCTRIG_EPWM1_SOCA;
    AdcRegs.ADCSOC11CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC12CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC13CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC14CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;
    AdcRegs.ADCSOC15CTL.bit.TRIGSEL  = ADCTRIG_CPU_TINT0;



    // ���ò�������(���ڿ�� = ACQPS_Value + 1)
    #define ACQPS_Value 6
    AdcRegs.ADCSOC0CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC1CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC2CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC3CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC4CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC5CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC6CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC7CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC8CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC9CTL.bit.ACQPS    = ACQPS_Value;
    AdcRegs.ADCSOC10CTL.bit.ACQPS   = ACQPS_Value;
    AdcRegs.ADCSOC11CTL.bit.ACQPS   = ACQPS_Value;
    AdcRegs.ADCSOC12CTL.bit.ACQPS   = ACQPS_Value;
    AdcRegs.ADCSOC13CTL.bit.ACQPS   = ACQPS_Value;
    AdcRegs.ADCSOC14CTL.bit.ACQPS   = ACQPS_Value;
    AdcRegs.ADCSOC15CTL.bit.ACQPS   = ACQPS_Value;
    #undef ACQPS_Value

    // ���ò���ͨ�����ȼ�:ͨ��0 & 1 : Ϊ���ٵ�������ͨ��,�����������,��Ϊ������PWMʱЧ
    AdcRegs.SOCPRICTL.bit.SOCPRIORITY = PRIORITY_SOC0_8;

    // �����жϱ�־��������: �������ʱ
    AdcRegs.ADCCTL1.bit.INTPULSEPOS = 1;

    // ����ADC�жϴ���SOCx
    AdcRegs.ADCINTSOCSEL1.all       = 0;
    AdcRegs.ADCINTSOCSEL2.all       = 0;

    // �����ж��źŵĴ���Դ
    AdcRegs.INTSEL1N2.bit.INT1SEL  = ADC_EOC08;  //L_N�������
 //   AdcRegs.INTSEL1N2.bit.INT2SEL  = ADC_EOC04;  //CT2

   // ʹ���ж��ź�,��������ζ��ᴥ���ж�,������ʹ���ź�
    AdcRegs.INTSEL1N2.bit.INT1E     = 1;      //CT1
 //   AdcRegs.INTSEL1N2.bit.INT2E     = 1;      //CT2
   // ������������,���´β�������ǰǰ�β�����ɱ�־��������
    AdcRegs.INTSEL1N2.bit.INT1CONT  = 0;
    EDIS;

    DELAY_US(1000L);
}


/*************************************************************************
 *  Function: AdcFinish
 *  ����˵����  �ж�AD���������Ƿ����
 ************************************************************************/
Uint16 AdcFinish(void)
{
    Uint16 result = 0;
    if (AdcRegs.ADCINTFLG.bit.ADCINT1)
    {
        AdcRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;    //Clear ADCINT1
        result = 1;                              //ת�����
    }
    return (result);
}


/***********************************************************************************
 * The End
 ***********************************************************************************/

2016_newOBC_Adc.h

over 7 years ago

0 MatthewPate over 7 years ago

TI__Guru* 84390 points

Rayna,
Looking at the relationship in time of the ADC sample and the PFC current, it does appear that when the ADC sample is incorrect(vs what the scope sees) this is causing the control system to change the PWMs and the PFC current to spike.

1)If increasing the ADC sampling time removes the noise in the ADC reading, then either the default sampling time is too small to charge the internal S/H cap correctly or we are averaging out the real noise from the system. If customer knows the input impedance of the signal into the ADC pin, they can use the model in the DS to understand the time constants needed to get the correct charge passed.

2)If adding code in the ISR also changes the behavior(leaving the Sample time alone) then that would indicate that the noise in the system is real and we are moving the sample point in time if we are waiting to change the PWM behaivor. In this case it could be that increasing the sample time is simply averaging out the real noise in the system as state before.

Is the ADC sampling point very close to the switching of the system? If so it might be a good experiment to change the trigger point to move it farther away/closer to the switch point to see if this gets better or worse.

Best,
Matthew

0 MatthewPate over 7 years ago in reply to MatthewPate

TI__Guru* 84390 points

Rayna,
Wanted to check to see if we had any update on the above topic/post.

Best,
Matthew

0 Rayna Wang over 7 years ago in reply to MatthewPate

TI__Expert 3680 points

Hi Matthew,

Thanks for reminding, I just got the new information from customer.

1# Firstly, the PWM setting information---> the PWM1&2 are set as up-down model, 180° phase shift, the EPWM_SOC trigger generated at TB period point, once every two PWM cycle. And EOC8 is used to trigger the ISR loop.

I think the above could exclude the ADC sampling point very close to switching of system.

2# As the below ADC input circuits shown, the signals uC_V_AC_L(CHSEL for SOC6), uC_V_AC_N (CHSEL for SOC8), uC_PFC_A_I(CHSEL for SOC1, 2) & uC_PFC_B_I(CHSEL for SOC3,4) are connected with ADC pins of MCU.

After calculate, the Vin ADC sampling time is around 12.5us, while current ADC sampling time is around 1us.

Question: The both current and voltage sampling time are large, why just ADC voltage happens error sampling results?

3# If the ADC CHSELs repeated changing from ADCINB to ADCINA pins could cause the ADC sampling results error? As the below shown, the SOC5 to SOC8, the channels change from ADCINB to ADCINA which is for Vin sampling.

4# The last question, information from F2803x Silicon Errata document as the below shown, there need discard the first ADCResult value from the series of SOC0->SOC1->SOC2->SOC3. As the customer's code, EPWM2 trggers SOC0->SOC1->SOC2->SOC5->SOC6->SOC7-SOC8. Which ADCResult should discard in case there is incorrect value, SOC0 or SOC0&SOC5?

Thanks!

Best Regards

Rayna Wang

0 Rayna Wang over 7 years ago in reply to Rayna Wang

TI__Expert 3680 points

Hi Matthew,

Except the above information, do we need to check customer's C2000 compiler Optimization configuration?

Thanks!
Rayna Wang

0 MatthewPate over 7 years ago in reply to Rayna Wang

TI__Guru* 84390 points

Rayna,

I don't think we need to look at the compiler optimization just yet. I'd like to focus on the Q3 from your previous post:

Based on the trigger configuration I beleive that when EPWM2SOCA is received ADCRESULT0 will not always be reliable and should not be used. From configuration it looks like customer samples A3 on SOC0/1/2, so likely they are discarding and then averaging SOC1/2

The trigger EPWM1SOCA is a bit trickier; since the triggers are not in order(EPWM2SOCA has some triggers between the SOCs) there is possibility that depending on when EPWM1SOCA is received either SOC3 or SOC9 could be the first conversion from ADC idle. So, both ADCRESULT3 and ADCRESULT9 cannot be trusted since they could both be the first conversion from idle.

Finally SOC11 is the first conversion triggered by TINT0, so it would also be potentially bad/in error.

Can you confirm that customer is discarding these samples per above?

For your Q2, the switching between the A channel to B channel is interesting, since these are two different S/H capacitors. If either S/H cap(A or B) is unused for a long time it will re-settle to steady state voltage which may mean it needs more time to charge. If customer is observing correct time constant, based on S/H network then this should be covered.

Best,

Matthew

0 Rayna Wang over 7 years ago in reply to MatthewPate

TI__Expert 3680 points

Hi Matthew & Tommy,

Thanks for your reply, the ADC sampling issue happened in ADCSOC6 & ADCSOC8 channels which don’t need to be discarded.

From customer's information, 1. adding some code in ISR or "for" loop, the current spike either keeping existing or keeping disappeared. 2. increasing the ACQPS to 8, during the test period, the spike haven't appeared, but not sure the spike will always disappear whenever the system works.

By the way, the project is a production project, customer want us to help them to find the real reason. Do you have more ideas about the issue?

Thank you very much!

0 tlee over 7 years ago in reply to Rayna Wang

TI__Guru 62975 points

Rayna,

Can you see if the ADC advisory discussed in the following post might explain the observations: e2e.ti.com/.../2892844

-Tommy

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28035: TMS320F28035