TM4C1294KCPDT: Bulk Dev USB ID pin

Hi Ralph,

Ralph Jacobi said:

The USB PHY enables an integrated pull-up,

Ralph Jacobi said:

and an external element (USB connector) indicates the initial state of the USB controller (pulled down is the A side of the cable and pulled up is the B side)."

Regarding the A side being pulled down, the computer (A) side don't even have an ID pin so it must be referring to OTG or Host mode devices?

Various USB cable pin outs can be seen here: https://images.search.yahoo.com/yhs/search;_ylt=AwrEZ7B1sMBcDHcAvhUPxQt.;_ylu=X3oDMTByMjB0aG5zBGNvbG8DYmYxBHBvcwMxBHZ0aWQDBHNlYwNzYw--?p=usb+id+pinouts&fr=yhs-avg-fh_lsonsw&hspart=avg&hsimp=yhs-fh_lsonsw

Ralph Jacobi said:

If you disable the USB0ID pin such as by using ForceModeDevice, then both USB0ID and VBUS pins become unused by the USB peripheral and have to be configured by TivaWare GPIO API's.

Well I disabled the GPIO analog input PB0 and that failed to work, so ID is not being pulled high unless PB0 is configured? How can that be since analog ports can not have WPU? Alternatively forced ID high via HWREG call to USB_O_GPCS (below) and left +VBUS PB1 analog input configured. USB0 peripheral would not toggle VBUS power register bit or initiate an end pipe connection when A side of cable was plugged to computer. In both tests the stack device mode was first being set USBDeviceMode (below).

So it seems ID pin is actually Floating above 1.2v result of the analog input being configured and not as a result of ID pin design. Code below should work to pull ID high without PB0 being configured.  Note Tivaware (usblib.h) implies to externally pull ID pin high, not that it is internally being pulled high. The TM4C129x design guide in not correctly clarifying how to handle ID pin Bulk device mode via PB0 input. I asked forum about ID pin prior to custom PCB and Amit's answer was similar to yours. Seemingly no one is the wiser PB0 is floating above 1.2v not that USB0 pulls it high as it should pull PB0 high (internally) even if analog pin was not configured! That ID left floating is one reason any low level transient can easily bounce the endpoint client pipe.   

typedef enum
{
    //
    //! Operate in USB device mode with active monitoring of VBUS and the
    //! ID pin must be pulled to a logic high value.
    //
    eUSBModeDevice,   

Please review below configuration and suggest a way to Disable PB0 analog input and pull ID high yet leave PB1 VBUS pin input operational.

Test case:

// Enable pin 94 PL6 In-Analog for USB0 (DP)
MAP_GPIOPinTypeUSBAnalog(GPIO_PORTL_AHB_BASE, GPIO_PIN_6);

// Enable pin 93 PL7 Out-Analog for USB0 (DM)
MAP_GPIOPinTypeUSBAnalog(GPIO_PORTL_AHB_BASE, GPIO_PIN_7);

// Enable pin 96 PB1 In-Analog for USB0 (VBUS+5)
MAP_GPIOPinTypeUSBAnalog(GPIO_PORTB_AHB_BASE, GPIO_PIN_1);

// Enable pin 95 PB0 In-Analog for USB0 (ID) B side internal pull up
//MAP_GPIOPinTypeUSBAnalog(GPIO_PORTB_AHB_BASE, GPIO_PIN_0);

/* !USBModeDevice; operate as USB device. */
USBStackModeSet(0, eUSBModeDevice, 0); 


/* Use VBUS and force ID high */
HWREG(USB0_BASE + USB_O_GPCS) |= USB_GPCS_DEVMOD_DEVVBUS;

Ralph Jacobi said:

So after calling:

 /* Use VBUS and force ID high */
HWREG(USB0_BASE + USB_O_GPCS) |= USB_GPCS_DEVMOD_DEVVBUS;

Make your GPIO configuration calls for PB0 to set it with a pull-up resistor.

Contradicts my point PB0 is not free if WPU must be configured Digital. Again PB0 must be configured as ANALOG or DEVVBUS does not SEEM to force ID internally. Seemingly USB0 only forces ID pin states only for OTG or Host mode.

Alternatively If PB0 is configured Analog and we set USB_O_GPCS |= USB_GPCS_DEVMOD_HOSTVBUS and ID then being low still works with Bulk device, hum. If we don't configure PB0 at all  USB_O_GPCS does not force the internal state changes of ID pin. This test seems to confirm ID pin is left floating in either configuration for the Bulk device mode.

Perhaps USB_O_GPCS only pulls ID high or low for OTG or Host mode and not Bulk mode or VBUS PB1 must have PB0 ID with Bulk device stack mode? 

Ralph Jacobi said:

, then even if signals were injected into PB0, it would not impact the USB stack operation.

Exactly because the USB endpoint is not established or work at all. The idea is GPIO PB0 can then be used for other purpose other than USB0 ID pin but clarification was left out of datasheet. 

Hello Ralph,

Ralph Jacobi said:

I don't see how you are reaching a conclusion that the ID pin state is not forced right when you can't observe it

TP7 ID analog input PB0 on the EVM is floating just above ground when USB0 is supposed to pull ID up internally. If it were pulled up 2.9v or above should be present on TP7. When I connected TP7 via 1K to 3v3 less bouncing of USB endpoint client occurs. Either way ID analog PB0 input can not be disabled and use only VBUS signaling, it simply don't work.

Anyway having EVM used as debug UART via USB virtual com port  and TM4C1294 USB bulk device causes some kind of ground loop interference when both are connected to same computer..The USB peripheral is far to problematic of any ground shift on even a EMI filtered cable randomly bouncing the endpoint client.    

Ralph Jacobi said:

When the USB0ID is connected internally, the GPIO that is connected to TP7 IS NOT CONNECTED TO USB

I'm not talking specifically about ID configured internally +3v3 even being on TP7. Only that USB0 does not allow external VBUS toggle control when ID is configured internal. I was referring to the internal ID pull up resistor, (ID configured external) TP7 is still floating and should be pulled up. If ID analog signal were pulled up internally, TP7 would not be floating for stack mode Bulk Device. The PB0 analog input device would not be floating in a true analog port.

PB0 is not an AINx input, it is considered a special analog dedicated peripheral pin and seemingly is not connected external or internal no matter how it is being configured. Otherwise we should be able to configure VBUS external and ID internal unless the USB0 has to be configured for OTG mode. That is the question not being answered and why USB peripheral ignores that control configuration mode.

Ralph Jacobi said:

As far as endpoint client bouncing, I have never observed this on our EVM. If you want to provide an example project that I can load into my LaunchPad, I can see if I can observe this

You can verify the +3v3 supply noise level doubles via data spikes when host PC client makes a endpoint connection. Why is USB0 peripheral interfering with 3v3 power source? It seems there is MCU invaded by +/-DM differential pair when the client end pipe is opened by software. Perhaps some kind of series filter or isolation of +/-DM pair needs to be added? 

I never did like USB connects target to an AC powered computer and rather add the few IOT variables into the Ethernet GUI next to existing scope widgets. Past hoped to get the project files for National Instruments build of very stable Ethernet GUI but TI never did make project files public. NI scope widgets are 100 times more clear to read than GUI composers widgets away. Our GUI composer GUI required JTAG port, yet another non-isolated connection for high voltage to invade and ICDI symbols loading often crashes online target functions. Ethernet much like USB is real time client can connect/disconnect many times without disrupting target functions.

Ralph Jacobi said:

When USB0ID is pulled up internally, the GPIO for USB0ID is left to the GPIO peripheral functions of the TM4C.

Are you saying the datasheet Table 21-1 is wrong analog ID input PB0 is designed with internal pull up?

Ralph Jacobi said:

Meanwhile, internally, where you can't measure with any means externally, USB0ID is pulled up as you wanted.

That is not true since the endpoint is not established via VBUS toggling of PB1 and having ID pulled up internally if/when PB0 has not been configured! If ID were pulled up internally PB0 would not need to be configured as an special other Analog port for VBUS pin toggling to work. Logic seems to rule ID and or pin 95 floating in both configurations (internal/external) or ID is being ignored. 

Ralph Jacobi said:

Meanwhile, internally, where you can't measure with any means externally, USB0ID is pulled up as you wanted

From what I am seeing that would be an assumption. Though USB_O_GPCS is showing ID high/low CCS debug, in reality is being ignored externally as other posters have reported. One test would be to take TP7 low when it was configured to be high should disconnect the endpoint? Yet I did that very test via TP7 with no endpoint interruption, proof ID signal is not functional no matter how it is configured.  

Ralph Jacobi said:

As TP7 is connected to PB0, it will be observed as floating.

Point again TP7 should not be observed floating when ID input is pulled up as it connects to GPIO analog mux bidirectional logic! I've never seen any integrated analog switch ever block or become unidirectional to voltage in one direction, sort of a mute point. Just because AINx analog inputs pass through a shared switch (unidirectional) structure does not infer the same occurs for a direct connection into a USB0 peripheral ID analog structure, especially when it is claimed pin 95 ID input to be pulled up internally, e.g Table 21-1. 

Ralph Jacobi said:

The GPIO peripheral will see that PB0 is an unconfigured GPIO, and therefore it's state is floating.

How can that be when PB0 pin 95 is being configured for Analog GPIO as (ID input) in IOT firmware that was pre-loaded on every launch pad?

// Enable pin 95 PB0 In-Analog for USB0 (ID) B side internal pull up
MAP_GPIOPinTypeUSBAnalog(GPIO_PORTB_AHB_BASE, GPIO_PIN_0);

Ralph Jacobi said:

Table 21-1 is right, but the internal pull-up is assigned to the USB0ID connection internally and not to PB0 as a GPIO as a whole

Bulk device mode TP7 seems dysfunctional no matter how ID pin was/is configured - test it yourself... VBUS pin toggling alone can not connect a USB0 endpoint when ID has been pulled up internally and PB0 is not configured. Again only works internally after disabling both analogs PB0, PB1 and that is not Single VBUS pin signaling. It seems internal gates preempt Single pin VBUS signaling if PB0 has not been configured. Try forcing both polarities of ID pin internally with PB0 not configured and PB1 configured the VBUS pin signaling Does Not Work.

Perhaps we need to configure stack mode as OTG mode for (Single Pin) VBUS signaling? I have asked this question twice and not been answered.

Again PB0 is an Analog I/O not digital and any voltage present on ID pin internally will and should reflect directly on TP7 when PB0 has been configured as an Analog input. Otherwise the ID input silicon structure is flawed and explains why any minor transient easily bounces the end point client no matter how ID was configured. Even if there was an internal steering diode in series with peripheral ID input there should be a voltage >500mV on TP7 especially with CMOS silicon structures.

Ralph Jacobi said:

Regarding the endpoint is not established issue, again please give me a project to test on my LaunchPad to observe this, if I can't see and debug on my end, I don't have a way to help with that.

Simple test only require the use of DMM voltage check on TP7 and quickly confirms PB0 configured for analog ID pin 98 is not connecting to USB0 peripheral ID input as it should. Perhaps TP7 ID input is a configuration issue USBStackMode,  BulkDevice versus OTG device? Perhaps a pull up for ID input was never implemented as datasheet states? TP7 voltage should be near 3v or higher if ID has been pulled up internally and PB0 is configured analog, no excuses.. 

Point again it is not proper to leave TP7 floating <500mV above ground being CMOS analog input acts like an Antenna for stray EMI into GPIO MUX. For now have added 3v3 to 1k pull up into TP7 but still not sure ID is even connected internally or being an issue of BulkDevice mode.  

Hello BP101,

The question regarding needing OTG vs not is a good one, sorry I missed that in all the discussions before. First off, this section from the USB section of the D/S has some details relevant to your setup:

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.

Based on this, and depending your ultimate goal, you may want to avoid having OTG set for the USB controller as it has to be configured as a Host, or as a Device (which is what you are doing) in order to use GPCS to connect USB0ID to an internal level and free PB0 for use.

However, regarding the VBUS signaling, if you are getting signaling on VBUS along the lines of the host trying to start a session, and turning off VBUS at the end of a session for power savings, that sort of functionality is part of USB OTG. So at that point, you'd need to configure it as an OTG Device and have PB0 connected as USB0ID.

Also maybe useful to know, but VBUS for a self-powered USB bulk device would be treated like as follows, not sure that applies for your situation:

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.

Regarding the TP7 voltage vs floating, what is the exact configuration you are using for the USB peripheral when you make this measurement? Are you setting PB0 to be a USB Analog Pin and NOT setting the GPCS register to connect USB0ID internally to the pull-up? Last I saw, the code you post was enabling the internal connection which would explain why its floating based on the explanation I offered earlier in the thread. If you want to re-post the USB initialization API's you are using right now that lets you observe this, I can modify my usb_dev_bulk example and repeat your DMM tests.

Ralph Jacobi said:

Last I saw, the code you post was enabling the internal connection which would explain why its floating based on the explanation I offered earlier in the thread. If you want to re-post the USB initialization API's you are using right now that lets you observe this, I can modify my usb_dev_bulk example and repeat your DMM tests

You have to be a bit more specific what you mean by internal connection. Like I stated several times it don't matter if ID is being forced high and PB0 configured analog TP7 still floats in BulkDevice mode.

Ralph Jacobi said:

However, regarding the VBUS signaling, if you are getting signaling on VBUS along the lines of the host trying to start a session, and turning off VBUS at the end of a session for power savings, that sort of functionality is part of USB OTG. So at that point, you'd need to configure it as an OTG Device and have PB0 connected as USB0ID.

OTG device might just make a direct connection TP7 into ID input of USB peripheral as BulkDevice mode simply does not, TP7 floats in all GPCS or PB0 configurations. VBUS signaling is not for power saving mode rather to establish and reset client connection if suddenly suspended. OTG mode might confirm TP7 truly can connect into the ID input of USB peripheral to verify internal pull up is actually there. Supposedly ID pull up is always enabled in all modes, so that would be a good test OTG versus BulkDevice self powered mode over TP7. Not much going on with self power mode other than the Bulk descriptor relaying the VBUS power information to the host computer.

Ralph Jacobi said:

Regarding the TP7 voltage vs floating, what is the exact configuration you are using for the USB peripheral when you make this measurement?

Any and all BulkDevcie configurations of PB0 or GPCS ID pin the TP7 remains in a floating state.

Ralph Jacobi said:

Are you setting PB0 to be a USB Analog Pin and NOT setting the GPCS register to connect USB0ID internally to the pull-up?

I think you are mistaken as Table 21-1 describes a fixed pull up enable on ID input no matter what mode GPCS has been configured. The statement below taken from Table 21-1 is either false or dependent on the mode of the USB controller and that was assumed or left out, else the ID pin silicon structure is bugged.

USBID: This signal senses the state of the USB ID signal. The USB PHY enables an integrated pull-up, and an external element (USB connector) indicates the initial state of the USB controller (pulled down is the A side of the cable and pulled up is the B side).

BTW: USBStackModeSet() modifies the GPCS register ID/VBUS field bits depending on the device mode being set. Even if forcing GPCS ID bit field for high ID input sense and making PB0 analog input TP7 remains floating. It must have something to do with OTG and information was omitted or assumed in datasheet table 21-1.

Technically we should be able to disable PB0 in Bulk Device mode and force GPCS ID bit field for high sense being the internal ID pull up is enabled in all device modes. As related several times ID input TP7 is acting like it has been disconnected in BulkDevice mode even when PB0 is configured as analog input and perhaps in OTG mode too, not yet tested.

Have you tested via DMM TP7 level after USB0 peripheral has simply been enable and PB0 configured as analog input? Table 21-1 does not state in order for ID pin pull up to function the GCPS register bit field must first be configured to some other non POR values.

Hi Ralph,

Well PB0 indeed is not digital but can be confirmed being active into USB0 if you pull TP7 down via 1K resistor. That renders session state protocol disabled no matter if GPCS very last step forced ID high and toggles control via VBUS PB1. That matched the behavior I noticed by not configuring PB0 as analog input pin for TP7. Discovered GPIOPinTypeUSB() was configured analog INPUT versus HW peripheral which seems to make PB0 control the ID input and TP7 still floats either way. That also has DM+/DM- set as analog Input versus proper HW keeping consistent with other peripherals that use AFSEL register to identify the USB peripheral, not the GPIO or SW has control. Tivaware calls sometimes deviate peripheral configuration from that which was proven and written in datasheet text.  

I had previously run a jumper wire PB0  via series 1K to +3v3 and removed jumper to test a pull down to ground, so PB0 pin 98 would not be left floating. Oddly as stated above the state of ID via GPCS does not function when forced Low to match PB0 input being grounded to stop the floating of TP7, even via Device Host where VBUS PB1 controls sessions state and ID is forced low.