TMS320F28388D: ePWM interrupts may not be executed during USB communication

Hi Vince,

Vince said:

Do you happen to be using nesting by any chance? I'm wondering if this is some nesting enable/disable issue.

What does it mean that interrupt nesting is used? As you have stated, USBA has a lower interrupt priority than ePWM, so we believe that nesting by interrupts does not interfere with PWM. Is my understanding correct?

Thanks,

Conor

Hi Conor,

Thanks for your follow up. The nesting I am referring to is when you enable other interrupts to occur inside another interrupt. For example, if you enable other interrupts to happen inside the EPWM, then it could cause the EPWM to get delayed. See below guide on nesting for an explanation of how that could happen. Basically: if you put "EINT" inside your EPWM ISR, you are allowing other interrupts to happen, which could be what you're seeing.

https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html

Now, it could also happen if you're connected to the debugger (debugger can pause PWM outputs I believe)

Regards,

Vince

Hi Vince,

As a result of our investigation, we believe that the problem lies in the way the API is used.

・API related to the USB being used
(1) USBBufferRead()・・・Reading data via USB
(2) USBBufferDataWriten()...Write data via USB

The problem occurred when the USB-related API was called while the interrupt processing (50us) caused by ePWM was not being performed.

When a USB write or read is performed, interrupts are occupied when large data is handled, and ePWM interrupts are not given priority, making ePWM real-time processing impossible.

I would like to do one of the following, but is there any way?

〇 Make ePWM interrupts the highest priority processing with multiple interrupts
〇 Use USB API processing as background processing without occupying interrupts. In other words, we want to prevent ePWM processing time from being delayed by USB processing.

Thanks,

Conor

Hi Vince,

The following interrupt is executed during USB device initialization processing.
・Interrupt_register(INT_USBA, &f28x_USB0DeviceIntHandler);

This interrupt processing is executed when the USB line is connected to the PC using H/W, but is this interrupt processing necessary? Also, is it possible to ignore this interrupt processing? The following two functions are called inside the corresponding interrupt processing.
・USB0DeviceIntHandler();
・Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);

What does the "USB0DeviceIntHandler();" function do internally? I've tried various things by manipulating the nest settings, but I haven't found a fundamental solution. All I can think of is that for some reason the USB processing interrupt is interrupting and interfering with ePWM processing.

Thanks,

Conor

Hi Conor,

I have reached out to the USB expert to reply to this. I am not a USB expert, but my assumption would be that the USB interrupt processing is definitely necessary upon connection to the PC.

For the other questions mentioned, I will let the USB expert comment.

Regards,

Vince

Hi Vince,

Thank you, I look forward to hearing from our USB expert.

Conor, 

The USB interrupt processing is necessary upon connection to the PC, it is during this time that the enumeration process is done to determine what type of device/host is connected. 

As Vince suggested, you can allow other interrupts to occur inside another interrupt so that the ePWM interrupt can be triggerd from the USB interrupt.

Best Regards

Siddharth

Conor, 

Pls refer the link - https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html for details on interrupt nesting.

By default , when an interrupt occurs , other interrupts are automatically disabled .  Hence in the USB ISR,  the interrupts have to be enabled  to allow CPU interrupts with a higher user priority to be serviced. You can refer the "interrupt_ex3_sw_prioritization" example included in C2000Ware.  In this example,  the Timer ISR sets the global and group priority to allow CPU interrupts with higher priority . 

Best Regards

Siddharth

Hi Siddharth,

From your answer we understood that we need to do two things.

1. Disable "EINT" in the EPWM ISR to prevent other interrupts from occurring. This prevents delays in interrupt processing within the EPWM ISR.

2. Enable “EINT” in the USB ISR to allow other interrupts to occur. This prevents interrupt processing within the EPWM ISR from being delayed due to the USB ISR.

Regarding 1., it is the default setting, so I don't think there is any need to change it.

Regarding 2, it is necessary to add a description to enable other interrupts within the USB ISR. I checked the sample code, but I couldn't understand how to give priority to ePWM interrupts. What do I need to change? Since ePWM probably has a higher interrupt priority than USB, is it okay to just enable IER and INTM within the USB ISR?

Thanks,

Conor

Conor,

Since ePWM has higher priority, it should be fine to enable the interrupt within USB ISR.The general rule here is that any enabled interrupt ( higher priority )that is pending (has its flag set) will immediately interrupt whatever ISR routine you are in (again, provided all enable bits and masks are enabled)

Best Regards

Siddharth 

Hi Siddharth,

Even if we set the interrupts correctly, including multiple interrupts, the problem still persists. As far as I can see from the waveforms, while the PWM ISR is running, the USB ISR is waiting for an interrupt and is working as configured.

Here's what I think the problem is:
Since there is no detailed information about the function in the documentation provided by TI, is it possible for you to answer the following?

Q1.
What exactly is executed by the "USB0DeviceIntHandler" ? Assuming that the function is executed when USB is connected, why is an interrupt being executed periodically about once every 100 us?

Q2.
Why does the access frequency of "USB0DeviceIntHandler" increase when transmitting data from a higher level? When the host issues a command to send data via USB, the access frequency of "USB0DeviceIntHandler" increases irregularly. Is this function looking at something by polling?

Thanks,

Conor

Siddharth,

We apologize for the inconvenience due to a request from an END customer, but we would greatly appreciate it if you could give us your opinion today.

Conor, 

The "USB0DeviceIntHandler" is used to handle SOF interrupts.  The host sends an SOF periodically and hence this ISR is called to handle it.  These serve as sort of "keep alive" signals.  When data is transmitted , there will other interrupts triggered and hence the frequency of "USB0DeviceIntHandler" will increase since this is the entry point for the USB interrupt handler

The source code for the USB library is available at <C2000Ware>\libraries\communications\usb\f2838x if you want to take a look. 

Best Regards

Siddharth

Hi Siddharth,

I understand that USB0DeviceIntHandler() periodically checks the connection with the host using the SOF signal.

There is a high possibility that the response of USB0DeviceIntHandler() will be delayed because the priority of ePWM is high compared to USB and the processing of ePWM interrupts takes a long time. Could this be a problem?

Also, as you can see from the waveform, USB0DeviceIntHandler() is called frequently when sending data to the PC (host) side. Could you please provide details about when USB0DeviceIntHandler() is called?

Thanks,

Conor

Conor, 

USB0DeviceIntHandler is the main USB interrupt handler entry point for use in USB device .  This ISR determines the interrupt and branches to the appropriate application or stack handlers depending on the current interrupt status. 

Best Regards

Siddharth

Hi Siddharth

,Problem solved. The cause was that other interrupts were not allowed within the USB interrupt.
By enabling other interrupts within the USB interrupt, the ePWM interrupt now takes priority. Thank you for your response.

Thanks,