TMS320F28075: CLA read ADC result issue

Hi Emma,

1. Is the CLA task that is reading the ADC being triggered by ADC interrupt? If yes, how is the ADC configured for generating interrupt -  is early interrupt being generated?

2. Can you also confirm that AdcResultsRegs.ADCRESULT3 type is Uint16 and Uint16 is being mapped to unsigned short on the CLA side. If you can post assembly code for the C code where ADCREAULT3 is being read then we can confirm if the right ADC results register is being read.

Thanks,

Ashwini

Ashwini,

Thanks for your reply.

Ashwini Athalye said:

1. Is the CLA task that is reading the ADC being triggered by ADC interrupt? If yes, how is the ADC configured for generating interrupt -  is early interrupt being generated?

INTPULSEPOS = 1 so it is not early interrupt.

Ashwini Athalye said:

2. Can you also confirm that AdcResultsRegs.ADCRESULT3 type is Uint16 and Uint16 is being mapped to unsigned short on the CLA side.

As I put last time. unit16 is mapped to unsigned short on CLA side.

Ashwini Athalye said:

If you can post assembly code for the C code where ADCREAULT3 is being read then we can confirm if the right ADC results register is being read.

...

BR

Emma

Ashwini,

Ashwini Athalye said:

If you can post assembly code for the C code where ADCREAULT3 is being read then we can confirm if the right ADC results register is being read.

BR

Emma

Hi Emma,

Is the fClaAdcResult variable a float variable> Can you try reading that to a uint16_t type variable and check?

Regards,

Veena

Veena,

As showed in CLA code, Customer read the ADCRESULT3 and judge the value less than 10 or not.

in normal condition there is no count. 

in abnormal condition, the count is still encreased.

So I don't think fClaAdcResult will impact this.

BR

Emma

Hi Emma,

Thanks for the additional information. I am still not clear a 100% on what the customer expects to see and what the customer is getting.

Emma Wang said:

Then they draw the ADC result and CLA reading ADC result using their own GUI.

Green line is ADC result.

Red line is CLA reading result, and sometimes it is too high sometimes it is too low.

Is the green line showing ADC result 3 being read from C28 CPU and is the red line ADC result 3 being read by CLA at around the same instance - I assume ADC is set to interrupt C28 and CLA to be able to capture these results.

It looks like red line is showing 1/2 the value shown in green line. Am I reading this correct?

Emma Wang said:

Next they check the ADC result in CLA directly and it is not right, either.

They did not give the register to a variable but just read the value and judge. The value should NOT below 800 as showed in the graph.

Why is the application checking for < 10 and not < 800 as value should NOT be below 800.

Thanks,

Ashwini

Ashwini，

Emma Wang said:

1. Confirm CLA typedef information. As showed in this thread, just check whether this error. e2e.ti.com/.../c2000-cla---accessing-adc-results-register-from-within-cla-task

 

I just found they just put the useful CLA type define in their source file and before including other header file.

I read throug all the CLA ADC issue thread, just found it is the main root cause

1.so I just want to check, if they put the type define in source code, it is same as including “F2837xD_Cla_typedefs.h” ?

2.for the code they just read the ADC value and judge in CLA task.(the fifth code in this screen shot)

what the data type will be?

3.I furture debug on the code and keep all the assembly code. 

I found the compare instruction is too complicated.

why MR0 logic shift left 16bits and a logic shift right 16 bits, Could this cause data overflow?

the CLA status register is 

I don't know NF=1 means what?

I also paste the key code in CLA here and the assmebly code attach.

void sAdcValCalc1(void)
{
__asm(" MDEBUGSTOP");
if(AdcaResultRegs.ADCRESULT3 < 10)
{
uwClaAdcResult[2]++;
}
fClaAdcResult[0] = ((stADCInCla.RGridVolt.ZerVal + stADCInCla.RGridVolt.PrdVal)*0.5)*(GRID_VOLT_RATIO);//stADCInCla.RGridVolt.ArithVal
fClaAdcResult[1] = ((stADCInCla.SGridVolt.ZerVal + stADCInCla.SGridVolt.PrdVal)*0.5)*(GRID_VOLT_RATIO);//stADCInCla.SGridVolt.ArithVal
fClaAdcResult[2] = ((stADCInCla.TGridVolt.ZerVal + stADCInCla.TGridVolt.PrdVal)*0.5)*(GRID_VOLT_RATIO);//stADCInCla.TGridVolt.ArithVal
uwClaAdcResult[1] =AdcaResultRegs.ADCRESULT3;
uwClaAdcResult[3] =stADCInCla.RGridVolt.PrdVal;

// MUX
switch(AD1_MUX_LEVEL)
{
case 0:            // switch 0
stADCInCla.PVVolt[PV1].ArithVal = (stADCInCla.PVVolt[PV1].ZerVal + stADCInCla.PVVolt[PV1].PrdVal) * 0.5 * BT_VOLT_RATIO; // PV1
stADCInCla.BTCurr[PV1].ArithVal = (stADCInCla.BTCurr[PV1].ZerVal +stADCInCla.BTCurr[PV1].PrdVal) * 0.5 * BT_CURR_RATIO;// - stADCInCla.BTCurr[PV1].offset;
        break;

    case 1:          // switch 1
     stADCInCla.PVVolt[PV2].ArithVal = (stADCInCla.PVVolt[PV2].ZerVal + stADCInCla.PVVolt[PV2].PrdVal) * 0.5 * BT_VOLT_RATIO; // PV1
     stADCInCla.BTCurr[PV2].ArithVal = (stADCInCla.BTCurr[PV2].ZerVal +stADCInCla.BTCurr[PV2].PrdVal) * 0.5 * fAdcRatio[1];// - stADCInCla.BTCurr[PV2].offset; // PV2
         break;

     default:
         break;
}

do you found any thing wrong?

CLA_Task_AdcSample.asm

I also want to change to the newest compiler but I met an error, since it is not related to CLA. I put into another link.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1077007/tms320f28075-change-compiler-issue

BR

Emma

Hi Emma,

1. It looks like the correct data type is being used - if header file is removed and types are specified in the source code then the types defined in source code will be picked up. From the assembly we can see that the ADCRESULT3 has been converted to 0xB03 address in the assembly code which is the correct address. If the type was incorrect, the address would have been incorrect.

2. Given that the type is an unsigned type, the Left and Right shift operations do seem unnecessary - the operations are needed for signed types however so that the 16-bit value gets correctly sign extended as a 32-bit value. Given the ADCRESULT is an unsigned short type and 12-bit value, the most significant bit will always be 0. The shift operations should not result in a negative number.

Does this code fail always or at a certain times only? Could there be some issue with when the ADC conversion and CLA task get triggered?

Thanks,

Ashwini

Ashwini,

Acturally, the same code and same board failed at a certain times.

And more weird thing is, during the failing time. the CLA reading result is not all wrong. it may be 1 wrong value followed a right value.

and it may happen that the voltage is correct and the current is wrong or vice verse.

another thing, they changed to newest compiler V21.6.0 and still wrong.

I am really confused by this phenomenon. and customer is eager to solve the issue or find a work around method.

BR

Emma

Hi Emma,

It's a bit hard to diagnose - at least I don't see anything wrong with the CLA code. Some suggestions I can offer to help debug this:

1. Add a large number say 10s of NOPS (or as much as can be added without affecting the system response) at the start of the CLA task to determine if there is some timing issue with when the task triggers and ADC value gets sampled.

2. If instead of the CLA task being triggered, the same code is executed on C28 interrupt, does that show the same issue? If not, please check that the CLA task is being configured to trigger exactly the same way the C28 task is being triggered. Maybe it will help if GPIO is toggled inside the CLA task ... this way it may be easier to check on scope to see if CLA task is being triggered as expected.

Thanks,
Ashwini

Hi Emma,

Emma Wang said:

It happened at specific condition: the inverter is connected to the grid normally, and then the PV source voltage is pulled down and disconnected from the grid, it may trigger an error

In the state mentioned above, does anything happen to the ADC, the device, or device pins that is different than other states?  Is it possible that one of the analog (or digital) pins experiences a voltage greater than VDDA + 0.3V or less than VSSA - 0.3V?  Is it possible that this state is noisier than other states, causing noise to couple into the ADC input or into the ADC reference?  

In the image where you have green and red waveforms, are you sure that you get 1 CLA ADC reading for every 1 C28x CPU ADC reading?  

Ashwini,

1. have customer try your first suggestion.

they add several NOPS.

• when NOPS is 50, it still give a wrong value.but ,it is not zero now. it is about 190.(the normal value should be about 2048)
• when NOPS is 80, it still give a wrong value.but ,it is about 1700.(the normal value should be about 2048)
• when NOPS is 100, It will stuck in the CLA task since it is too long.

however, they told me the C28 reading result is correctly always, above is CLA reading result.

2.They do the ABBA test. and the issue is along with C2000 device.

3.there is 4 choose 1 ADC sample front circuit for some temperature or other not important samples,when it is fixed. the CURRENT sample (another SOC and ADC channel)issue will be solved. Could you kindly explain this phonomenon?

BR

Emma

Hi Emma,

I'll defer to Ashwini on the CLA reading debug, but another easy debug strategy you might try is to directly copy the ADC results to the buffered DAC output at each read in both the CLA task and in the CPU ISR.  You can then go and look at the buffered DAC waveform on a scope as the system is running to see what the ADC is producing.    

Hi Emma,

Thanks for running the experiment. Few other suggestions:

1. Has the CLA task been profiled to check if it completes before being triggered again i.e. there is no overrun. The CLA has the MIOVF register to detect task overflow - could you remove the NOP and add a check at the start of the task to check if overflow flag is set and correlate whether the overflow is set only when ADC reads a bad value?

2. If there is no overflow then I would suggest profiling say with GPIO and looking on a scope to confirm that CLA task performing the ADC read and the C28 code performing the ADC read are occuring at the same time - maybe CLA task is not being triggered as expected at certain times.

Thanks,

Ashwini

Devin,

Devin Cottier said:

In the state mentioned above, does anything happen to the ADC, the device, or device pins that is different than other states?  Is it possible that one of the analog (or digital) pins experiences a voltage greater than VDDA + 0.3V or less than VSSA - 0.3V?  Is it possible that this state is noisier than other states, causing noise to couple into the ADC input or into the ADC reference?  

after some test, they did found when the issue happened, The ADC pin will at -0.5V or 4.8V

what will it cause ?do we have a document describe on it?

BR

Emma

Hi Emma,

These voltages are beyond the absolute maximum ratings, so the device could be damaged. Even if the device is not damaged, operating outside the device operating conditions can result in incorrect functional operation.  

In addition to the voltages, it might also be worthwhile to check the clamping current on these ADC pins when the issue is occurring.  Since the ADC inputs have ESD protection diodes, usually the pin itself will not experience the applied voltage, but will instead start sinking current into the VDDA rail or sourcing current from VSSA.  Series resistance on the ADC input can be used to limit the clamping current to prevent permanent damage to the device.