• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 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.

TMS320F28075: TZ interrupt without source?

sagar dhavali
Intellectual 555 points
Part Number: TMS320F28075


Hi,

I have the following setup to EPwmRegs1

- GPIO is routed to TZ1 via input X-bar. (GPIO is inverted in the setup)

- An under voltage signal to TZ3 via input X-bar.

- TZ5 and TZ6 are as usual system clock fail logic and EMUSTOP resp.

When interrupt occurs, I read the TZOSTFLG register, I see the value as 1 ie, OST1 is 1. But I do not see GPIO value read as 0. It stays at 1! (It should be 0 when TZ1 becomes active; otherwise 1)

My question is that, is there any reason why would ePWM1_TZ gives an interrupt when there is no input from external input? Or Am I doing anything wrong?

// Source 1
EALLOW;
GpioCtrlRegs.GPAINV.bit.GPIO31 = 1; 	/* TZ active low - Input inversion control for this pin */
GpioCtrlRegs.GPACTRL.bit.QUALPRD3 = 0;  /* Qual period = SYSCLKOUT = 10ns */
GpioCtrlRegs.GPAQSEL2.bit.GPIO31 = 2;  	/* Qual Samples = 6; Total samples=10 and if input is high for 6 samples (6*10ns=60ns), then it is REALLY high. */
GpioCtrlRegs.GPAPUD.bit.GPIO31 = 1;    	/* Enable pull-up on GPIO (TZx) - 1: Disables the Pull-Up. */
InputXbarRegs.INPUT1SELECT = 31; 		/* INPUT1 is link with TZ1 - PFC_TRIP */
EDIS;

// Source 2
EALLOW;
GpioCtrlRegs.GPBINV.bit.GPIO52 = 1; 	/* TZ active low - Input inversion control for this pin */
GpioCtrlRegs.GPBCTRL.bit.QUALPRD2 = 0;  /* Qual period = SYSCLKOUT = 10ns */
GpioCtrlRegs.GPBQSEL2.bit.GPIO52 = 2;   /* Qual Samples = 6; Total samples=10 and if input is high for 6 samples (6*10ns=60ns), then it is REALLY high. */
GpioCtrlRegs.GPBPUD.bit.GPIO52 = 1;    	// Enable pull-up on GPIO (TZ3) - 1: Disables the Pull-Up.
InputXbarRegs.INPUT3SELECT = 52; 		/* INPUT3 is link with TZ3 - BP_UVL0V_TRIP */
EDIS;

__interrupt void epwm_PFC_B_tzint_isr(void) /* PFC - Inverter must stop since PFC stop - ePWM1_TZ */
{
T_u32 tmp_time_0;
T_u16 tmp_defect;

//tz.epwmx_pfc = PWM_MOD_1->TZOSTFLG.bit.OST1; // Reading a 1 indicates a trip has occured on the OST1 selected event.
tz.epwmx_pfc = EPwm1Regs.TZOSTFLG.all;
tz.counter_pfc++;

RST_SYS_status.tab_fifo_error[12] = GpioDataRegs.GPADAT.bit.GPIO31;
RST_SYS_status.tab_fifo_error[13] = GpioDataRegs.GPBDAT.bit.GPIO36;
RST_SYS_status.tab_fifo_error[11] = GpioDataRegs.GPBDAT.bit.GPIO52;
RST_SYS_status.tab_fifo_error[0] = GpioDataRegs.GPBDAT.bit.GPIO32;
RST_SYS_status.tab_fifo_error[1] = GpioDataRegs.GPBDAT.bit.GPIO33;
RST_SYS_status.tab_fifo_error[2] = GpioDataRegs.GPBDAT.bit.GPIO34;
RST_SYS_status.tab_fifo_error[3] = GpioDataRegs.GPBDAT.bit.GPIO35;
RST_SYS_status.tab_fifo_error[4] = GpioDataRegs.GPBDAT.bit.GPIO37;
RST_SYS_status.tab_fifo_error[5] = GpioDataRegs.GPBDAT.bit.GPIO38;
RST_SYS_status.tab_fifo_error[6] = GpioDataRegs.GPBDAT.bit.GPIO39;
RST_SYS_status.tab_fifo_error[7] = GpioDataRegs.GPBDAT.bit.GPIO40;
RST_SYS_status.tab_fifo_error[8] = GpioDataRegs.GPBDAT.bit.GPIO49;
RST_SYS_status.tab_fifo_error[9] = GpioDataRegs.GPBDAT.bit.GPIO50;
RST_SYS_status.tab_fifo_error[10] = GpioDataRegs.GPBDAT.bit.GPIO51;

AdcdRegs.ADCSOCFRC1.bit.SOC6 = 1;
//wait for ADCD to complete, then acknowledge flag
while(AdcdRegs.ADCINTFLG.bit.ADCINT1 == 0);
AdcdRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;
tz.temp = ADCD_getValue(6) * ADC_COEFF_FLOAT_D15_MUX_Y6;

// Acknowledge this interrupt to receive more interrupts from group 2
PieCtrlRegs.PIEACK.all = PIEACK_GROUP2;
}

I am reading RST_SYS_status.tab_fifo_error array values in my log file.

  • 0
    Intellectual 555 points
    Is it the right place to read GPIOs?
    Is there any chance that, GPIO (Source 1) would have caused the interrupt but in ISR, by the time I read GPIO if it has gone to low, I will be reading latest value ie, low which is what I am getting in the log. Is that so?
  • 0 in reply to sagar dhavali
    TI__Genius 15260 points
    Hi Sagar,

    Depending on your input source to the trip, the GPIO could certainly change values by the time the ISR comes around. Are you able to scope the GPIO to verify if it is toggling?

    Regards,
    Kris
  • 0 in reply to Kris Parrent
    Intellectual 555 points
    I tried to but its too noisy. We're operating at high power! Can't differentiate noise and actual signal. In this case, I think my best reliable source is to read interrupt flag register and see what has caused the interrupt.
  • 0 in reply to sagar dhavali
    TI__Genius 15260 points

    Sagar,

    The issue that you're likely going to run into is the device isn't going to differentiate between the noise and the actual signal. Whenever you cross the threshold of the GPIO to read as a '0' you're going to get a trip. This includes if it is just a noise spike on the pin.

    If you want to time how long the ISR takes, you could setup an eCAP to also be connected to that pin. Use the eCAP to latch when the pin toggles then in the ePWM ISR you could read the current eCAP counter. This will tell you the number of SYSCLK cycles between the event and the ISR. But that really only helps to confirm that the ISR is delayed long enough to not read it in the ISR.

    On your scope images that you provided in a different post ( https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/615194/2266599#2266599, where is your probe relative to the device? If you can get it as close to the device as possible that should help us see what the device is "seeing".


    Regards,
    Kris