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.

TMS320F28379D: Unexpected value from TMS320 GPIO (Controller frozen )

Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMS320F2837

Hi 

I am using TMS320F28379D controller for motor drive PWM geneartion. However sometimes middle of the motor run, I got constant GPIO output of  3.3 V when i operate 90% duty ratio and 0 V when it below 20 % duty ratio. I am curiosity to know at what condition this will happen and under TMS freeze condition,  What value will TMS320 send ? 

epwm configuration settings:

EALLOW;

// Disable pull-up on and gonfigure as EPWM
ATI_HUBMOTOR_PULL_UP = 1;
ATI_HUBMOTOR_MUX = 1;

EDIS;

hubmotor->TBCTL.bit.CTRMODE = TB_COUNT_UP; // Count up
hubmotor->TBPRD = REARMOTOR_TIMER_TBPRD; // Set timer period
hubmotor->TBCTL.bit.PHSEN = TB_DISABLE; // Disable phase loading
hubmotor->TBPHS.bit.TBPHS = 0x0000; // Phase is 0
hubmotor->TBCTR = 0x0000; // Clear counter
hubmotor->TBCTL.bit.HSPCLKDIV = TB_DIV2; // Clock ratio to SYSCLKOUT
hubmotor->TBCTL.bit.CLKDIV = TB_DIV1;

//
// Setup shadow register load on ZERO
//
hubmotor->CMPCTL.bit.SHDWAMODE = CC_SHADOW;
hubmotor->CMPCTL.bit.SHDWBMODE = CC_SHADOW;
hubmotor->CMPCTL.bit.LOADAMODE = CC_CTR_ZERO;
hubmotor->CMPCTL.bit.LOADBMODE = CC_CTR_ZERO;

//
// Set Compare values
//

hubmotor->CMPA.bit.CMPA = 0; // Set default A value
hubmotor->CMPB.bit.CMPB = 0; // Set default A value
//
// Set actions
//
hubmotor->AQCTLA.bit.ZRO = AQ_SET; // Set PWM1A on Zero
hubmotor->AQCTLA.bit.CAU = AQ_CLEAR; // Clear PWM1A on event A,
// up count

hubmotor->AQCTLB.bit.ZRO = AQ_SET; // Set PWM1B on Zero
hubmotor->AQCTLB.bit.CBU = AQ_CLEAR; // Clear PWM1B on event B,
// up count
}

From the figure it was observed that from 12 sec to 17 sec we missed the communication from delfino (TMS320F2837) (UART to USB ) and observed vehicle stop. However it restarted communication and went until 30 sec, after 30 sec again we observed delfino communication and observed vehicles moving more fast (This will happen only when motor driver receives constant 3.3 V) .
In the first incident our PWM value was very low and might be due to that the GPIO pin settled at zero and second incident GPIO might be settled at high since our pwm value was max at that condition.

We want to know at what condition this will happen and at what condition the TMS320 will automatically reset.

In any case TMS320 will hang (frozen) ?
We have been working on the same hardware and firmware from more than 5 years and observed two times in the span of 3 months this incident  even after replacing TMS320 board also.

Please let me know the cause of incident.

  • Hi Malakondareddy,

    Some initial questions (sorry for so many, but just trying to gather all the information to assess):

    1. How often does the issue occur? Is there a pattern to when it occurs? And does it occur every time you change the duty cycle to >90% or <20%?
    2. When you say the "GPIO" pin, you are referring to the PWM signal (e.g. EPWM1A is on GPIO0), is that correct? This is not some arbitrary GPIO?
    3. Is the duty cycle the only parameter than changes between cases of the signal going high vs. going low?
    4. Does the SCI communication disruption correlate with the PWM incorrect high/low activity?
    5. Do you have oscilloscope captures of the PWM and/or SCI when these issues have occurred?
    6. What is your target PWM signal (what is it supposed to look like - do you have any trip zone or digital compare submodule configurations, or is it only those you listed above?)? When/how are you changing the duty cycle?

    Best Regards,

    Allison

  • TMThanks for your reply ,

    1. How often does the issue occur? Is there a pattern to when it occurs? And does it occur every time you change the duty cycle to >90% or <20%?

    Reply: Currently we are using 150 boards with same TMS320 from past 6 years but recently we have seen this incident in the span of three months (two times) after changing  the board also.

    2. When you say the "GPIO" pin, you are referring to the PWM signal (e.g. EPWM1A is on GPIO0), is that correct? This is not some arbitrary GPIO?

    Reply : sorry its my mistake. we are using EPWM1

    3. Is the duty cycle the only parameter than changes between cases of the signal going high vs. going low?

    Reply : Yes only duty cycle will vary respect to our reference command and its fixed frequency (24kHz) 

    4. Does the SCI communication disruption correlate with the PWM incorrect high/low activity?

    Reply: we are not using any SCI communication

    5. Do you have oscilloscope captures of the PWM and/or SCI when these issues have occurred?

    Reply: we could not capture this waveform because the board is on running vehicle .

     6. What is your target PWM signal (what is it supposed to look like - do you have any trip zone or digital compare submodule configurations, or is it only those you listed above?)? When/how are you changing the duty cycle?

    Reply : Its only what i listed above, we duty cycle we will vary whenever we need to change vehicle speed. 

    We lost the USB communication when this incident happen. The TMS320 board is connected to compute board through USB cable to monitor and send reference spped to TMS320 and also do other activities. However when this incident happen time there is no communication between the Compute board and TMS320 board. 

  • Hi Malakondareddy,

    Since this issue has only occurred twice in the past 6 years (although only recently), that does indeed make it quite difficult to find the source. Your EPWM configurations look correct, and the EPWM is capable of using the full duty cycle range (and can even go to 0% and 100% duty if configured as described/implemented in this application note), so that shouldn't be a concern.

    Have you been able to recreate the issue in your system? Does this only occur at very low/very high duty cycle ranges? Have you been able to monitor the device's power rails, reset lines, etc. when this happens? The EPWM behavior and loss of communication may be symptoms of a different issue occurring, but it is hard to tell without more data at the time of fault.

    Best Regards,

    Allison

  • Hi Allison Nguyen,

    Have you been able to recreate the issue in your system?

    Reply : No, I could not recreate

    Does this only occur at very low/very high duty cycle ranges?

    Reply: I can't say exactly but as per data it is occurring at 0 and 25 % duty ratio

    Have you been able to monitor the device's power rails, reset lines, etc. when this happens?

    Reply :Yes, we did not see any voltage fluctuation or under voltages at this condition.

    The EPWM behavior and loss of communication may be symptoms of a different issue occurring, but it is hard to tell without more data at the time of fault.

    Reply : Shall we have virtual meeting so that my team can explain in details about this? Please let me know when we will have this.

     

    Did you observe this behaviour in any case ?

  • Hi Malakondareddy,

    I will say it is difficult to hypothesize much initially without further information/data or being able to recreate the issue.

    Yes, we can absolutely have a meeting- I am interested to hear more information about the context and issue. I have not observed this so far, but I will also ask a few colleagues who have been here longer to see if they have any ideas as well. I just sent you a friend request on E2E, so if you accept and private message me I can share my email and coordinate with you there.

    Best Regards,

    Allison