This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
What is the point of top secret handling USB datasheet information when design engineers have to pay an yearly fee to redistribute USB anyway? Frankly after dealing with all the issues of data transport handling misinformation, interrupt failures and other random crashes it seems an futile attempt by the USB authority to continue that practice. Not withstanding how some past TI engineers had interpreted the USB protocol for device handling leave me believing they were/got confused. That can be seen when USB peripheral VBUS pin is shorted out from high current flow plugging cable in and a 1uf MIN cap is not present on the input. Perhaps with good reason any capacitor value added to the VBUS pin seems to inflict the droop detection register area of the peripheral even when it is not being used in device mode.
Part of the problems I have been dealing with "to be nice" revolve around (usb.c) handling of 3 different device modes (device, host, OTG). Between (usbdenum.c) attempts to confuse handling, hardware controls of VBUS/ID pins and NDA datasheet missing register BIT clarifications any real attempt to have USB (rapidly) remarketed for Windows client use seem futile. Another key area USB0_INT58 interrupt handing of register USBIE (interrupt enable) and software failing to clear the NVIC global interrupt specified in (startup_ccs.c) or registered anywhere in code. It really doesn't matter since USB0_INT58 is not working in device mode and may have issues in other modes, IDK! However USB0_INT58 is not being properly cleared, unpend seems next best way absent any INTClearUSB0().
That said I have reviewed the handling of device mode VBUS/ID pins was confused by several calls, according to foot notes written in device defines of the three modes handling of USB/ID pins.
The handling of USB stack passed variable and how (usbdenum.c) determines the modes after updating (usb.c) to match verbatim, below. There seems one call missing (usb.c) to force device mode, added into (usbdenum.c) handling of USBStackModeSet(). No wonder I was so confused when the VBUS pin had eventually shorted out from high current after plugging USB cable 100's of times into host computer. Passing the variable eUSBForceDevice had no effect on USB_O_GPCS since it was absent.
// // Force VBUS/ID high, device mode if requested. // if(g_iUSBMode == eUSBModeForceDevice) { //MAP_USBDevMode(USB0_BASE); HWREG(USB0_BASE + USB_O_GPCS) |= USB_GPCS_DEVMOD_DEV; } else if(g_iUSBMode == eUSBModeOTG) { // // To run in active device mode the OTG signals must be active. // This allows disconnect to be detected by the controller. // MAP_USBOTGMode(USB0_BASE); } else { // // In all other cases, set the mode to device. This function should not // be called in OTG mode. Actively monitor VBUS and ID must pull high. // g_iUSBMode = eUSBModeDevice; MAP_USBDevMode(USB0_BASE); }
//***************************************************************************** void USB0DeviceIntHandler(void) { static uint32_t ui32Status; /* Unpend the USB global NVIC interrupt */ //IntPendClear(58); // // Get the controller interrupt status. // ui32Status = MAP_USBIntStatusControl(USB0_BASE); // // Call the internal handler. // USBDeviceIntHandlerInternal(0, ui32Status); }
Hi Ralph,
Perhaps off the cuff all appears proper for Bulk device handling, look more closely and do a few tests of your own.
Ralph Jacobi said:and it is INT 58 (vector #)/INT 42 (actual interrupt number).
Actually 42 is the bit number in debug registers not the Tivaware (hw_ints.h) registered vector 58.
Ralph Jacobi said:Regarding the examples usefulness, we have a long list of customers who made products that went into market starting with the bulk example and building their custom applications on top of it with no need to modify any part of the USB stack at all to back up the fact that it works as needed for our customers to quickly get to market with the device.
The pend clear (INT58) is my patch and did nothing to clear the registered (startup_ccs.c) interrupt and handling that never occurs. USB0 is not a registered semaphore interrupt and must be cleared on entry to the vector interrupt handler routine below. If USB0 bulk device is supposed use a Semaphore or GPTM timer to call the INT58 vector where/how is that ever being configured?
EDIT: USB Reset cycled several times plugging cable even though the INT status had been cleared more than one time. That behavior makes it seem INT58 was being ignored by the application.
Thus call below (usb.c) was also configured incorrectly to force VBUS/ID pins high (0x3), according to foot notes (hw_usb.h) 0x3 is to call StackModeSet(0, eUSBModeForceDevice, 0).
The proper pin states for device mode sets (USB0_O_GPCS = 0x1) not forcing VBUS/ID high. Otherwise if that is not correct the foot notes for the hex decodes need to be corrected (hw_usb.h).
//***************************************************************************** // //! Change the mode of the USB controller to device. //! //! \param ui32Base specifies the USB module base address. //! //! This function changes the mode of the USB controller to device mode. //! //! \note This function must only be called on microcontrollers that support //! OTG operation. //! //! \return None. // //***************************************************************************** void USBDevMode(uint32_t ui32Base) { // // Check the arguments. // ASSERT(ui32Base == USB0_BASE); // // Set the USB controller mode to device. // HWREGB(ui32Base + USB_O_GPCS) = USB_GPCS_DEVMOD; //USB_GPCS_DEVMODOTG | USB_GPCS_DEVMOD; }
Hello BP101,
Perhaps this information will help:
When used in OTG mode, USB0VBUS and USB0ID do not require any configuration as they are dedicated pins for the USB controller and directly connect to the USB connector's VBUS and ID signals. If the USB controller is used as either a dedicated Host or Device, the DEVMOD field in the USB General-Purpose Control and Status (USBGPCS) register can be used to connect the USB0VBUS and/or USB0ID inputs to fixed levels internally, freeing the PB0 and PB1 pins for GPIO use. For proper self-powered Device operation, the VBUS value must still be monitored to assure that if the Host removes VBUS, the self-powered Device disables the D+/D- pull-up resistors.
Also note that the USBDevMode API should only be called when in OTG mode.
I do agree the comments on the footnotes in hw_usb.h are a little unclear as these really don't describe much:
#define USB_GPCS_DEVMODOTG 0x00000002 // Enable Device Mode #define USB_GPCS_DEVMOD 0x00000001 // Device Mode
I don't think your modification is needed though as the settings are right for OTG, and if you aren't using OTG operation then as the API says, you should not be using it.
Ralph Jacobi said:Question regarding how you are checking for interrupts in the USB0DeviceIntHandler, did you go ahead and unlink the .lib files from your project and link in the driverlib and usblib folders to allow the project to actually compile and give debug access to files like usb.c and usbdenum.c?
The USB library files are imported into CCS project folder and use them as build dependency and have library/paths set. Yet the interrupt vector is coded to access USB0DeviceIntHandler() which never occurs. If USB0_INT58 was occurring for the device disconnect events (0x004 USBIS) or Resume status checks, several UARTprintf messages would appear but never do. The bulk device composite driver configuration does not appear to supersede or take control of hardware interrupts or clear the status until it has been 1st handled by the caller INT58. Oddly if I treat INT58 as Semaphore SW trigger from a 5ms GPTM intervals, nothing different occurs. That seems to align with INT58 is not functional as a typical NVIC controlled interrupt source or never has been.
Below is the results of the USB analyzer points of EP1 random close. The playback of the log file 4 (Bulk Stream1) indicates me unplugging cable few times to restart the connection for random code 0x5 events.
HI Ralph,
The log really don't show anything but the host did not respond to the last request for 200 bytes, 0xC000.0005 common failure code. Out (UP) end pipe could not send requested packets since it abruptly aborts the pipe. At times suspect electrical disturbance is even worse but the OUT end pipe never aborts and frequent intermittent aborts at other times of high AHB activity. If I time the USB re-connect just right the OUT end pipe stays connected for extended periods (minutes) before aborting. If NVIC is not busy with PWM0 pends the OUT end pipe stays connected for hours and rarely aborts but has been detected aborting non the less.
The real question remains how is INT58 vector not calling the registered handler and checking USBIS status flags configured in (usbdenum.c)? The bulk device driver (usbdenum.c) appears to have originated TM4C123 MCU and later tweaked to work with TM4C1294.
It would seem (usbdenum.c) is highly suspect in this odd behavior especially since the registered INT58 vector handler is not being called. Perhaps INT58 handler has been called twice, once previously or alternatively registered somewhere in the USB library, higher up in the stack? INT58 vector seems to handle the cable connect but not to or from the registered vector call in (startup_ccs.c). That would imply either INT58 is hard wired to USB0 and or the vector handler call is automatically being unpend by the USB controller. Can't have non-disclosed semaphore interrupts running amuck on the AHB without the designer knowing about them! If USB0 requires semaphore interrupt handling should be noted in the datasheet, without NDA being required.
/cfs-file/__key/communityserver-discussions-components-files/908/usb_2D00_monitor5.2.zip
Hello BP101,
I went ahead and put together a properly constructed project which will demonstrate that the USB interrupt does go to USB0DeviceIntHandler and can breakpoint there. In fact, it should have a breakpoint set within the ISR when you first download it into CCS.
This is for the EK-TM4C1294XL: usb_dev_bulk_debugtest.zip
Go ahead and run this on your LaunchPad to see that the interrupt does fire, and then review your own project and see if you can track down where you aren't including the right files to allow you to debug the USB library which will let you see the interrupt firing in your project.
Hi Ralph,
Part of the INT58 issue was being caused by Eclipse import of USB library files into project tree. Modifications (usbdenum.c) control endpoint were compiling to usblib.lib of the original SW location debug folder, not the one imported into project tree. I was expecting the usbdenum.c changes to compile with the application. The project library file/folder path made no difference and the application project reference to USB library in project tree was ignored. After reimporting USB library as links only rather than work from local files usbdenum.c changes then compiled with the application.
The debug messages are finally printing now but plugging in cable produces several USB resets even after the INT status was cleared. It seems 0xC0000005 Suspend is a known issue some programmers have dealt with in the past. For now the connection is more stable at 32 byte control messages, 64 bytes packets but still has Suspend popup at times. Part of the issues was usbdenum.c enables all end pipe interrupts but only EP0 is the interrupting source in a Bulk stream. That also clamed down the frequency of Suspends and EP0 smaller message packet size. Clear to see fewer revolving resets during cable re-plugging when PW0 is running seemingly will make the pipe connection easier to re-establish via client methods.