5509A USB cancel data send

Yoyu might have already considered this. How about setting the SOFTRST bit in USBGCTL? Make sure the FRSTE bit is set, which is the default setting anyway. It clears all pending interrupts except the RSTR interrupt.

Regards.

We can confirm the FRSTE bit is set in the USBCTL register. As perviously mentioned we are using the CSL USB_resetDev function which sets SOFTREST bit in the USBGCTL register. This has no effect in our situation, we still have the data being sent via the IN pipe.

We believe the SIE, as described on page 20 of TMS320VC5507/5509 DSP Universal Serial Bus (USB) Module Reference Guide (SPRI596A) contains the data and is buffering it. Can you confirm whether the SIE will buffer the data in a disconnect, and is it possible to flush the data from the SIE?

The USB_resetDev function emulates a condition after a usb module reset. As the concern was with preventing usb to send out data or cancel the data transaction, would you have also tried using the functions USB_disconnectDev, USB_abortTransaction and USB_abortAllTransaction? These actually deal with aborting transactions with the selected/all enpoints and tri-stating the USB D+/D- lines.

We have attempted to use all the functions you mention to prevent the data from being sent unfortunately the data is still sent. We believe the issue is related to the fact that data has already entered the SIE, and the only method that seems to clear the data in the SIE is to perform a DSP RESET.

USB_disconnectDev function just disconnect the USB module from the BUS, it does not appear to clear the data in the SIE.

USB_abortTransaction clears the count and stop the DMA transfer from the endpoints buffer. When our issue occurs the data has already left the endpoint buffer as far as we can tell, and is within the SIE.

USB_abortAllTransaction just calls USB_abortTransaction on all the currently enabled endpoints.

Would you've also considered resetting the USB module by a) explicitly setting the RESET bit0 in the CTRLR reg 0x8004, and b) from the system level, by

setting the USB_RST bit3 in the System Control reg PRCR 0x1c05?
Could you please try using instead, the following statements in your code where you'd called the USB_restDev() function?
a) CSL_USB_REGS->CTRLR |= CSL_USB_CTRLR_RESET_MASK;

OR

b) CSL_SYSCTRL_REGS->PRCR |= CSL_SYS_PRCR_USB_RST_MASK;
while(CSL_SYSCTRL_REGS->PRCR & CSL_SYS_PRCR_USB_RST_MASK);

OR

c) both a) and b) together

The NAK bit is not accessible for the user. Neither is it available for the CPU. It's used only in the USB state machine and can be set only by the USB Buffer Manager(UBM) and must be subsequently cleared by the CPU or USB-DMA.

Moreover, if setting the same at IP level somehow, didn't prevent the data from being sent out- you're right, the data might be pending with the SIE. NAK gates the data flow between the Buffer RAM and the UBM. If it couldn't, it would mean UBM has already picked up the data and sent it out to SIE.

But the CPU, at the moment, has NO direct control over this engine. Hence, could you check if the options mentioned above work?
None of the functions tried by you before, USB_resetDev(), USB_abortTransaction() and USB_abortAllTransaction(), set these bits.

We cannot find a description of the CTRLR regiser at address 0x8004 or of the PRCR  register at addres 0x1c05 withing any of the documentation for the 5509 DSP.  Which technical reference manual are they described in?

Regret the misleading input. 5509a indeed doesn't have the above regs. Please allow me to correct. Could you please try working out any of the following bits?

Do call the API _vUSB_resetFirmwareEnv() first to clean up the Endpoint handles.

1) FEN in USBCTL - Clear the same. The USB function will be inactive.

2) Ensure FRSTE in USBCTL is set. Set SOFTRST in USBGCTL again. Once it's cleared, USBRST in USBIDLECTL - Clear the same. USB module should stick to RESET state. OR try just clearing only the USBRST bit with FRSTE set.

3) Idling clock to peripherals - Ensure IDLEEN in USBIDLECTL is set. Then set the bit3(the one for peripheral idle) in IDLE Control Register 0x0001. This should shut off the clk supply to peripherals, including usb. Check the status in IDle status register 0x0002.

Each step could be tried individually.

Could you also try combinations of the above steps as well?

First thanks for you assitance in troubleshooting this issue.

Unfortunately due to a pending deadline, we have made some modification at a higher level in our code to prevent this situation from occurring by eliminating a very hard to catch race condition. By eliminating this race condition we no longer get into a scenario of this occurring.