--The C8051F341 has EP0 including vendor commands, EP1 for bulk IN transfers, and EP2 for bulk OUT transfers.
--EP1 utilizes most of the USB bandwidth, and has double-buffering Enabled. It always sends 64 byte packets (full).
--My code is in assembly.
--I have 2 interrupts enabled
#1 USB Interrupt Service Routine (Low Priority).
#2 Timer-2 set for every 5uS.
-Receives data from another uC via asynchronous FIFO and stores in 128k x8 SRAM circular buffer.
-Transmits data to that other uC via another asynchronous FIFO.
-Moves 64 Bytes from SRAM circular buffer and fills USB-FIFO.

The USB-ISR reads CMINT, IN1INT, and OUT1INT, storing them in local variables, then decodes, starting with EP0, then EP1, then EP2.

The EP1 function call within the USB-ISR sets a flag when an interrupt is received, then polls for the flag to be cleared by the high-priority T2 interrupt after it moves data from SRAM. The USB-ISR, then polls IPRDY again to see if alternate FIFO (double buffering) is open and resets flag and waits.

This works, but I have found that when I slow my EP1-IN data rate (asking for less data), the device is left waiting for 64 bytes of data to be ready to transmit, and thus the USB-ISR is stuck waiting for that flag.

Effectively, I miss EP0 vendor commands, which occur after I have entered the USB-ISR and read it--in which case they would have been handled before the EP1 function call, but before exiting the EP1 portion of the USB-ISR.

Does this mean that IN1INT can only be set while the device is not in the USB ISR?

I tried moving the arming of IPRDY and checking for 2nd FIFO open our of USB-ISR, so that the device did not sit in the ISR waiting for data to come in on T2 interrupt. This removed the issue, but introduced an issue where packets were sent prematurely (I believe) exhibiting channel skipping on my software for odd channel counts since at 2-bytes per sample, even channel counts never span consecutive bulk packets. (64/6 bytes per sample set, 3 channels enabled, means 10 consecutive samples fit into packet number n, with 2 of 3 channels stuffed into last 4 bytes)...

Thanks for reading, and for any suggestions.
-Josh

It's fine, but,

> then polls for the flag to be cleared by the high-priority T2 interrupt after it moves data from SRAM.

Don't wait for T2 interrupt in the USB-ISR. EP1 handler in the USB-ISR finishes just by setting the flag.

You need to implement another process, which polls both of EP1 and T2 flags in main loop. This process fills EP1 FIFO when both flags are asserted. Disable USB interrupt while this process is filling EP1 FIFO, to ensure exclusive access of the USB engine.

I have things working now, with EP1 data loaded from SRAM to the USB FIFO in the Main loop. I'm still unclear on effect of double buffering, as the F341 data sheet (16.12.1.Endpoints1-3 IN Interrupt or Bulk Mode, page 181) states:
Hardware will automatically reset INPRDY to ‘0’ when a
if double buffering is enabled for the target endpoint, it is
IN FIFO at a time. In this case, hardware will reset INPR
packet into the FIFO and sets INPRDY to ‘1’. An interrup
only be generated when a data packet is transmitted.

Since the EP1 portion of the USB_ISR is setting my flag allowing the USB FIFO to be filled, does this mean I have effectively disabled double buffering?

On another note, I was quite surprised to see that the MOVX command can apparently be interrupted before the command has completed. I had noticed when I changed code that much of my data was corrupted. If I disable T2 interrupt around my Main Loop MOVX command

CLR ET2
MOVX A,@DPTR
SETB ET2

the issue is cured... I perform context save and return on both the accumulator, and the data pointer in my T2 interrupt, so this seems wrong. My take is that the MOVX command which now requires adjustable timing registers allowing interface with slower SRAM, may not have been fully tested, when configured that way, and that it may allow an interrupt to occur after the minimum number of SCLKs that MOVX may be configured for--any thoughts?

Thanks,
-Josh

To use double buffer effectively, the firmware polls INPRDY bit of IN EP1, instead of the flag set by USB_ISR for EP1. When INPRDY bit is 0, the FIFO accepts another packet.

> I was quite surprised to see that the MOVX command can apparently be interrupted before the command has completed.

It's the first time I heard that off-chip MOVX is disturbed by interrupt.
I'll test on this issue.
Ask it to SiLabs support, too.
http://www.silabs.com/support/pages/contacttechnicalsupport.aspx

Tsuneo