Usb library: Interrupt

Hi,

1) Yes it is normal to have an interrupt every 1ms. It is from the SOF (start of frame) packet which is sent by the host to ensure the device it still alive.

2) You could be able to use polling. This would obviously require some modification to the software.

3) Because servicing the USB interrupts takes so long, it may be better to use a lighter weight serial communication.

What are you using the USB communication for? How much data? What is the throughput you need?

sal

Hello

I tried to use in polling mode: I have disable USB interrupt (IER register group 9) and call the USB handle interrupt in the background loop.

But this not work.

We can't replace the USB link to common serial link because many computer today does not have serial port!... So our product must be used by a large industrial public.

At the moment, I just disable USB interrupt in my Main ISR of 100µs, then it is not interrupted by USB. But it can be delayed if USB interrupt occurs just before.. :-(

On the controlCard, SCI or UART communication can be done through the FTDI and USB connector on the card.

You can use UART communication through the FTDI chip and USB connector which connects to your PC. This may be a good option.

sal

Hello,

Yes with the ControlCard this is a good solution, but we currently use this "demonstration card" in waiting our own board.
In this custom board, we will not have the FTDI chip!

Is something like this an option? www.amazon.com/.../B008AGDTA4

sal

Thank for your try,
But our product must out with an "Micro USB" connector.
The end user must use a standard cable "Micro USB" <-> "USB-A" to link to its computer

Polling should be possible, as long as the device can respond to the SOF packet and DATA IN and DATA OUT request packets fast enough.

How long if your MainISR? Can you describe what you mean by it didn't work more?

sal

Hello

To make simple, my soft is based on IDDK example.

Then, I have a MainISR with a period of 100µs. The time spent in this ISR can vary from <1µs up to about 50µs (Motor control loop, trajectory compute etc...)

I have another ISR (with HI priority) of 6,25µs period. Like in the IDDK example, this ISR is to manage the motor feedback resolver and compute the motor position angle. This time spent in this ISR is 600ns (and 2,34µs every 100µs which correspond to Sinus output waveform period)
 
After that, we have the background task in which I guess manage the USB.

So the Resolver ISR interrupt the MainISR, but 600ns to 2.5µs is acceptable.

Now if MainISR is interrupted by the USB ISR, this can take upt to 16µs, this is not acceptable in my application to take this jitter
 
I test to compile and flash the USB bulk example. This is Ok, but when I run and connect USB to my computer, nothing is happening. USB is not detected by computer. I not done other manipulations that this!

First, you can disable the SOF interrupt trigger to save some processing power. It's for optional timing synchronization; it's not used by default.

I suggest using interrupt nesting to allow your main ISR to interrupt the USB ISR. We have a guide here:

processors.wiki.ti.com/.../Interrupt_Nesting_on_C28x

You can also look at the sw_prioritized_interrupts example in controlSUITE.

If you have an F2837xD, you can move the main ISR to CPU 2 to avoid the USB overhead completely.

Hello,

I followed your advice, bellow is the feedack:

-1) Nesting Interrupt: Like group 9 is only used by USB, I the following code:

In MainISR (100µs period) at the begining of the function:

IER &= ~M_INT9;
EINT;          

In Usb ISR, at the beginning of the function:

  EINT;

With this, the USB interrupt can be preempted by MainISR, but not the reverse. This work correctly, then I have not jitter on MainISR. => Ok

-2) Disable SOF.

With debugger, I set in registers view / UsbaRegs/USB_IS_IE/ USBIE from 11111111 to 11110111 (SOF bit enable)

With this, USB work correctly, but the interruption time is not changed (period of 1ms and spend time between 2.6µs to 16.8µs when not interrupted by my Main ISR)

SOF bit set to 1 or 0 not change these time

-3) I have a CPU2 because on the control card it is a 377D. But on my final custom board, we will use the Single core (377S)

I'm glad to hear that the jitter is gone.

Your 1ms interrupts might be the host (PC) polling the USB device for updates. If you monitor the USB traffic, you should be able to tell what's going on. We use hardware bus analyzers here, but there's also free Windows software like USBPcap.