TMS320F280049C: ePWM TZ Faults Issue in InstaSPIN Implementation

I don't think there are any issues with EPWM and XBAT that are not discussed in the file of F280049C errata.

You might refer to the example code in motorControlSDK, and just need to remove the TZn linked to the XBAR input if your board doesn't have the TZn input.

Please check the settings in HAL_setupCMPSSs() if the CMPSSn is connected to the related the ADC inputs according to your board.

Yanming Luo said:

You might refer to the example code in motorControlSDK, and just need to remove the TZn linked to the XBAR input if your board doesn't have the TZn input.

Here is the HAL_setupFaults() function in which I've commented out X-BAR configuration of GPIO40 (nFAULT signal). Rest of the setupFaults function is kept the same for TRIP7, 8, and 9 signals.

    //XBAR_setInputPin(XBAR_INPUT2, HAL_PM_nFAULT_GPIO);
    //XBAR_lockInput(XBAR_INPUT2);

Yanming Luo said:

Please check the settings in HAL_setupCMPSSs() if the CMPSSn is connected to the related the ADC inputs according to your board.

Based on Analog subsystem Fig 12-1 and 16.1 Introduction, CMPSSn is not connected to ADCs but instead connected to PGAs on Analog Interconnect bus. Did you mean PGA inputs to CMPSSn subsystem? Following is the configuration of the CMPSSn subsystem. 

- CMPSS5, 3, and 1 are being used for overcurrent fault protection and are connected to output of the PGA5, 3, and 1 respectively.

- Negative input of both the High and Low comparator in each CMPSS subsystem (5,3,1) is selected as 12-bit reference DAC which are referenced VDDA. Which was measured on the hardware as 3.33 V. 

- Initially, value of the DAC is set to half (2048) for high and low CMPSS then it is being modified in main() to appropriate value based on the max current by hardware. i.e. 3940 for High and 156 for Low comparator which represents +- 127 A max. 

- Oddly enough it shows overcurrent trip faults even though ADC (connected to PGA5,3,1) buffer results never go beyond this values. 

Attached is the image of AnalogSubsysRegs value showing CPMSS input mux with PGAs. 

Hi Yanming,

Do you have any update on this issue?

Hi Yanming, 

Upon further investigation, an additional issue I found that when the input values to the CMPSS system (from PGAs) is within certain range of the set negative input for both high and low CMPSS, ePWM starts glitching. Once the CMPSS +ve input values are above (for high comparator) or below (for low comparator) the set -ve input value, ePWM trip fault is successful and sets the ePWM in low states. 

For the testing purposes, DACA Out (0.0 V to 1.1 V) is used to vary the inputs of the PGAs (Gain 3) and the CMPSS subsystem is set accordingly DACLVALA = 1860 and DACHVAL = 2979 for Trip zone faults. ePWM glitches when the PGA output/CMPSS input is in either of these ranges - 1860 to 1887 and 2955 to 2979. This is because of the CTRIPL and CTRIPH signals being set randomly in these ranges. 

Why does CMPSS behave in this manner during certain range? What could be done to solve this problem? 

Best,

Amit

1. You may have a look at the pages below in datasheet, the ADC input can be connected to the related CMPSS, not only the output of the PGA.

SPRS945D, P97, Figure 5-31. Analog Group Connections
SPRS945D, P98-99, Table 5-39. Analog Pins and Internal Connections

2. Please refer to the code below to configure the digital filter and hysteresis for CMPSS.

        // Configure digital filter. For this example, the maxiumum values will be
        // used for the clock prescale, sample window size, and threshold.
        CMPSS_configFilterHigh(obj->cmpssHandle[cnt], 32, 32, 30);
        CMPSS_initFilterHigh(obj->cmpssHandle[cnt]);

        // Initialize the filter logic and start filtering
        CMPSS_configFilterLow(obj->cmpssHandle[cnt], 32, 32, 30);
        CMPSS_initFilterLow(obj->cmpssHandle[cnt]);

        // Set up COMPHYSCTL register
        // COMP hysteresis set to 2x typical value
        CMPSS_setHysteresis(obj->cmpssHandle[cnt], 1);

3. Please take a look at link below for configuring the ADC and CMPSS modules.

https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/911930/3380961#3380961

Hi Yanming,

I agree that ADC input can be connected to the related CMPSS in the same Analog group. What I meant was I am not using direct ADC (Gx_ADCAB or Gx_ADCC) as non-inverting input of the High and Low Comparator (CMPx_HP and CMPx_LP) but instead I am using PGAx_OUT. 

I had already change the configuration of the digital filter and hysteresis. Digital filter helped up to some extent but if Hysteresis made it worse. Which is really odd to me. It actually increased the Comparator threshold region instead of making it stable.

 Well I have configured the ADC and CMPSS modules correctly and tested them individually as well. 

What could be possible solution for this problem? Appreciate your help here. Let me know if you need more details.

Best,

Amit 

The hysteresis should be here always since the noise of the sensing signals and the error of the DAC of the CMPSS. I think the the variation range you mentioned above should be normal, you need to set an appropriate threshold for the CMPSS regarding the current protection value.

To back trace the issue, I also tested the PGAs input and output to compare and look at the gain and offset errors. These errors on PGA  are significant as the PGA input increases (on the higher side of the range) and I think this affects the CMPSS and makes hysteresis worst. 

Even though calling Device_cal() function in the device initialization routine didn't help in trimming these gain and offset errors at all. I believe that if these errors are addressed then probably it will alleviate the CMPSS issue as well. 

Is there a way to know the actual/near identical values of these PGA feedback resistors (Rout and Rgnd) to trim the gain and offset errors? 

If not then would you mind sharing some information on trimming these internal PGAs methodically instead of trial and error? or even if it is possible to do that in the first place.

Just to give you an idea about these errors, I am sharing the test results showing difference between ADC measured current values and external probe measured current values. 

 Best,

Amit

Hi Yanming,

Do you have any thoughts on this?

Best,

Amit

Hi Amit,

Perhaps it is more C++ related in how the assigned (variables) code was written to handle +/- CMPx-A/B trip values. Trip points set a range uint16_t versus a proper int16_t since negative integers then have sign to match the static trip thresholds being set. Making that change adding sign to both High and Low trip thresholds helped to reduce false DC trips from zero crossing spikes, even without PGA's being used. Yet it still required a higher static trip margin than expected even after adding excessive hysteresis to both comparators.

Perhaps a good point to observe adding any capacitance to inputs of PGA can extend the transient roll off time making the false trip issue more difficult to combat. In our case adding 2200pF to the 300pF pads, first removing 0R's and using external current sensors worked well for all but LAB5 motor ID Lq/Ld inductance.  The motor is low impedance and speed to 50-60Hz for inductance test eventually trips DC faults. The PWM gate signals in this part of lab 5 code gets real noisy drops the phase voltage to >half the bus voltage. It seems the modulation technique of FAST estimator motor ID has odd frequency harmonic SNR issues.

One other thing that seemed to help make the current probe closer to DAC trip settings was to first calibrate the ADC via call to HAL_calibrate. In effect I was filtering the INA240 outputs by using the on board x49c filter pads, disabling the PGA amplifiers and enabling the filter resistors. Also tried enabling PWM blanking with 25µs offset and blank one 50µs period on both CMPSSx H/L DC. That stopped the false trips but seemed a bit dangerous since I had disabled Tz2 for use with our test DC inverter and instead used DAC disables PWM outputs.

The low CMPSSx has inverted output and AC sine wave in the ADC 2048 count grows downward crossing 0V, should seemingly be signed integer values. Note the DACVALow register is set to a very low positive value 256 by default, labs.h. Yet that is the peak inverted or negative trip point count of 256, it seems to work at times as unsigned integer. Yet was odd to have unsigned values for zero crossing events that turn negative every 1/2 cycle samples counts are backwards, 2048 down to 256.

Hi Amit,

What current sensor are you using on your board? Shunt resistor? Or hall sensor?

You might find the Rout and Rgnd in section 14.3 of the F28004x TRM (SPRUI33C), and you should select the right external resistor to match the gain resistors.

Perhaps Amit's shop has closed down likely due to Covid19. Thinking of this issue a bit over time it seems the PGA amps do not detect zero crossing transient events much below ground? The INA240 differential amp detects to -4v below ground. Seemingly INA240 tasks CMPSS positive inputs in an odd way even with upward of 5.6k series resistance into the CPMSSx + inputs.

The major difference being the CMPSS + inputs were not centered +1.65v and unidirectional current detection sets 42mv offset just above ground. I mostly tested INA240 bidirectional output centered midref (+1.65v) and little difference fewer CMPSS false OVC trips was noted. In conclusion perhaps the PGA amps are better suited for CMPSSx OVC detection.

Hi Yanming,

I accidently hit the "This resolved my issue" but instead of "Reply". So to answer your previous question, we are using Shunt resistor in our application. Upon modifying the hardware and making  we're able to alleviate problem to some extent. Initially, it was causing over current fault 100% of the time during start up sequence now the CMPSS module causes overcurrent fault 20% of the time with out seeing any current spike on the scope. 

Best,

Amit

Hi Gl,

Thank you for your suggestions. I really didn't get time to implement and test it as have been busy with some other tasks. Will try to implement it and see if that makes any difference in our case. 

Best,

Amit

Hi Amit

Glad to hear your ok this virus is effecting so many. I'm not sure the filter values are set correctly in Yanmig's example, (32,32,30) defies TRM text. It really didn't matter what I set the filter sample values according to TRM text on the subject. The hidden truth being (labs.h) DACL/H trip values over write those set  HAL_setupCMPSSs().