mainISR

I missed GPIO 30 was configured as input (hal.c), how did it even work at all from mainISR calls? I configure it as output and not much difference for decimation pulse period or shape (J2 pin13) though it seem to pulse bit faster than 50µs. Since the PWM triggers SOC->EOC plus time from mainISR ROM calls so GPIO-30 pulse should be slightly slower than the PWM period, it ain't.

One major point of SVPWM is to reduce rotor vibration versus other modulation techniques, not increase rotor vibration as it is doing. Albeit this small PM motor has only 1 shaft bearing and rotor is sleeved by Teflon, if it should ever contact stator poles in near 0.040" air gap. Oddly 6 code modulation produces none of the noted vibration thus programming issue/s seem the most likely suspect! 

Also reducing the IRatedDelta made no difference to reduce rotor vibration during ramp up estimation >100Hz. 

//! \brief Defines the IdRated delta to use during estimation
//!
#define USER_IDRATED_DELTA_A       ((float32_t)(0.00002))//0.0001

    // GPIO30->Reserve (N/A), mainISR START/STOP
    #ifdef CLA
    GPIO_setMasterCore(30, GPIO_CORE_CPU1_CLA1);
    #else
    GPIO_setMasterCore(30, GPIO_CORE_CPU1_CLA1);
    #endif
    GPIO_setMasterCore(30, GPIO_CORE_CPU1);
    GPIO_setPinConfig(GPIO_30_GPIO30);
    GPIO_setDirectionMode(30, GPIO_DIR_MODE_OUT);// default was IN
    GPIO_setPadConfig(30, GPIO_PIN_TYPE_PULLUP);

This PWM period logic is in milliseconds and not 20Khz microsecond period 1/frequency. So to make 50us PWM mainISR then LED5 No longer pulses and motor ID flag jump to 1 prior to enable flag being set. Please do not write PWM period is microseconds if you mean it to be milliseconds as the later InstaSpin control period. Anyone will immediately think it a bug in timing if PWM period is indeed microseconds as the variable below shows.  Something in mainISR vibrates this motor during ID and it ain't the user.h preset motor settings. 

The same formula derives user control period in seconds and the angle delay user.c.

//! \brief Defines the Pulse Width Modulation (PWM) period, usec
//!
#define USER_PWM_PERIOD_usec    ((float32_t)1/USER_PWM_FREQ_kHz) //1000.0

//! \brief Defines the controller execution period, sec
//!
#define USER_CTRL_PERIOD_sec    ((float32_t)USER_CTRL_PERIOD_usec/(float32_t)1000000.0)

//user.c
    pUserParams->angleDelayed_sf_sec = (float32_t)0.5 * USER_CTRL_PERIOD_sec;

The GPIO30 toggles in ISR that's for the test in development, so the related configuration has been removed, but the test code was not removed accordingly. Sorry, confusing you, we will remove the test code also.

I can't find the code in the example project you mentioned above, it should usec with the formula "#define USER_PWM_PERIOD_usec    ((float32_t)1000.0/USER_PWM_FREQ_kHz)".

Yanming Luo said:

The GPIO30 toggles in ISR that's for the test in development, so the related configuration has been removed

There is a timing problem in mainISR GPIO30 not behaving as it should to show decimation timing. There is no missing code in mainISR, how else could we see decimation periods of mainISR? Based on x49c launch pad schematic J2 pin being GPIO 30 pin 39. BoosterPack quick card changed to reflect schematic J2/J4 since user guide suggest silk was wrong J6/J8 on card PCB but not J2/J4, was very confusing.

Again the scope capture of GPIO-30 is very odd shaped check it out your self. We do the same for other interrupts in TM4C1294 MCU and never see GPIO output signal with no period sustain. The GPIO-30 period is being chopped by the interrupt handler, otherwise should have full pulse period going to ground. Otherwise GPIO-30 V pulse (2 tips) seem to indicates extremely short execution time inside mainISR.

Yanming Luo said:

I can't find the code in the example project you mentioned above, it should usec with the form

1000/20.0=50 but not (0 .000050µs) that was why to try P=1/F thinking user parameter PWM frequency 20000Hz not simply 20.0 as it was defined. Point again being 50 is not 50µs unless perhaps a periodic triggered timer. InstaSpins EOC interrupt to maintain rotation angle seems to drift in and out of phase causing periods of negative torque cycles during and after ramp down. 

The motor flux is only stable by very low user phase current <0.5mA and fails to produce speed >155Hz in ramp up. In ramp down with >0.5mA user flux is highly unstable motor ID flag=1. No wonder others are having problems with motor ID is05 as the timing in mainISR is not keeping consistent. There is no way this motor should be vibrating like this even from very low user current. SPRUHJ1H–January 2013–Revised June 2019 never states the ramp up frequency 20Hz goes above USER_MOTOR_FLUX_EXC_FREQ_Hz states (LS,CL1,CL2,CL) makes it odd 20Hz rose up to 155Hz ramp up in watch window. How it do that when it was forced to 20Hz in Lab is05_motor_id.c?

Perhaps timing mainISR ends up causing truncated ramp up period <20 seconds as defined below. Motor can not reach peak Hz for flux detection via CL1 no matter IND/RES current setting. In this case MotorFreqHighHz (600Hz) rotor only reach 155Hz for values input IND/RES. Ramp down (CL1) seems to start <20 seconds rotor vibration results.

Perhaps over modulation causes speed issues or some other PWM triggered timing reduces the ramp up period HighHz cycle? The user is forced to set very low IND/RES current (<0.5A) to counter CL1 vibration and motor never (safely) reach MotorFreqHighHz (600Hz).  Otherwise user input IND/EST current (>1.0A) and ramp down has violent vibrations negative flux cycles. Square wave inverter output results phase voltages sharp rising edges small roll off during is05 motor ID. Find it odd the 3 PGA gain are set level 12 but you guys are the experts we are only reporters of issues when it don't work so well. 

6.5.5.2 Ramp-Up Time and Acceleration
The next parameter during the ramp-up state is the period of time while the motor is ramped up (Figure 6-17). This is set by default to 20 seconds as shown in the next code example from user.c file:

[EST_State_RampUp]
pUserParams->estWaitTime = (uint_least32_t)(20.0*USER_EST_FREQ_Hz);
//! \brief Defines the timer frequency for estimator, kHz
#define USER_EST_FREQ_Hz (USER_ISR_FREQ_Hz)

#elif (USER_MOTOR == NidecMotor_1)

#define USER_MOTOR_TYPE                   MOTOR_TYPE_PM
#define USER_MOTOR_NUM_POLE_PAIRS         (6)
#define USER_MOTOR_Rr_Ohm                 (NULL)//ACIM only
#define USER_MOTOR_Rs_Ohm                 (1.46257722)//1.45991349
#define USER_MOTOR_Ls_d_H                 (0.00211925316)//0.00223078486
#define USER_MOTOR_Ls_q_H                 (0.00211925316)//0.00223078486
#define USER_MOTOR_RATED_FLUX_VpHz        (0.0239039753)//0.0243388247
#define USER_MOTOR_MAGNETIZING_CURRENT_A  (NULL)//ACIM only
#define USER_MOTOR_RES_EST_CURRENT_A      (1.6) //++ to spin motor under load
#define USER_MOTOR_IND_EST_CURRENT_A      (-1.6)//-- to spin motor under load
#define USER_MOTOR_MAX_CURRENT_A          (2.0) // After ID never used again
#define USER_MOTOR_FLUX_EXC_FREQ_Hz       (20.0)
//#define USER_MOTOR_INERTIA_Kgm2           (7.06154e-06)

// Number of lines on the motor's quadrature encoder
#define USER_MOTOR_NUM_ENC_SLOTS          (NULL)

#define USER_MOTOR_FREQ_MIN_HZ             (5.0)           // Hz
#define USER_MOTOR_FREQ_MAX_HZ            (775.0)         // Hz

#define USER_MOTOR_FREQ_LOW_HZ            (10.0)          // Hz
#define USER_MOTOR_FREQ_HIGH_HZ           (600.0)         // Hz

#define USER_MOTOR_VOLT_MIN_V             (12.0)          // Volt
#define USER_MOTOR_VOLT_MAX_V             (24.0)          // Volt

Note (iso5_motor_id.c) statement over rules (user.h)  #define USER_MOTOR_FLUX_EXC_FREQ_Hz . The WA requires the patch below. Seemingly LC state detection is not meant to run at such low rotor speeds (Hz) according to SPRUHJ1H–January 2013–Revised June 2019. There are new states CL2, RR not discussed.

CL2 seems to ramp motor upto 1.3krpm after state OL flux. Patch allows (300Hz - 500Hz) state OL, PM not stall lock rotor in this state via higher frequency. Yet LC state still vibrates rotor but less noticed at higher Hz speed. It seems LC is not being correctly identified since cogging seems to be an integral part of _IND_EST_CURRENT_A and LAB guide instructing we match it with _RES_  makes it worse. It seems IND (-) current needs to be less not equal to reduce negative torque via LS state.

    //
    // Set some global variables
    //
    motorVars.pwmISRCount = 0;          // clear the counter
    motorVars.speedRef_Hz = USER_MOTOR_FLUX_EXC_FREQ_Hz;  // set reference frequency to 300.0Hz
    motorVars.accelerationMax_Hzps = 10.0; //defines starting maximum acceleration and deceleration for the speed profiles,

Did you have any captured waveforms to show the problems you mentioned above if possible? That should help us to fully understand your questions. Thanks!