I guess your problem is blocking of interrupts while handling an interrupt.
Are you taking too much time to handle an interrupt ?
Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ?
This low level routine can then handle both usb and result bytes input.
Higher level routines can then poll for data in the circular buffer.
Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.
Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?