Tiva launchpad tm4c123gxl USB babble error

Hello Sisco.

A search on the forum shows that similar issue with babble interrupt and possible WAs.

e2e.ti.com/.../400921

Regards
Amit

Hello Amit,

Thank you for your response, i noticed that this person has problems while using the launchpad as USB host. My device is connected as a bulk device to a PC host so i am not sure what to do with the information in that thread.

i currently don't have access to my source so i will have to do some more research tommorow, but i don't think the other persons problem can help me.

Thanks,
Fransisco

Hello Fransisco,

Check for what is the clock source being used. It must be the Main Crystal and not PIOSC.

Regards
Amit

Hello Amit,

is use the following line of code to set the clock source:

SysCtlClockSet(SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_2_5);

USB communication starts out fine but after some time (sometimes 10 minutes, sometimes 10+ hours) the device disconnects (windows usb hotplug sound from the USB reset command) and my USB analyzer software reports a babble error.

The launchpad USB device does not crash or reports any errors and i can reconnect from my PC software without problems again to continue communication.

Fransisco.

Hello Fransisco,

1. Check by replacing the USB cable. Sometimes a faulty cable may be the cause
2. The use of Main Oscillator is not an issue unless the crystal shows sign of wear and tear. Check if the solder are still clean and there is no oxidization on the metal solder.
3. Check if the VDD supply is stable.

Regards
Amit

Hi Amit,

I have tried several times with a different cable and am encountering a different error (Stall). The USB device firmware keeps running and after some time of Stall errors the endpoint stops giving errors and the transfers just time out.

When sending data from the host (PC) to the device it is not received on the launchpad and the USB_TXIS/USB_RXIS are not getting set. I can also see the UNDRN and ERROR bits are set in USB_TXCSRL1.

Fransisco

Hello Fransisco,

I do see 1024 byte packet. Could it be leading to buffer corruption? Without a LeCroy or Protocol Snooper it is going to be tough to know what is happening on the physical layer.

Regards
Amit

Hello again Amit,

The 1024 Byte buffer you see is the host PC issuing an IN token (USB transfer (read) using a 1024 byte buffer).

libusb_bulk_transfer (struct libusb_device_handle *dev_handle, unsigned char endpoint, unsigned char *data, int length, int *transferred, unsigned int timeout)

The endpoint then responds with a stall.

Sisco

Hello Fransisco,

Are you sure that the packets being sent on the bus are being fragmented as 64 bytes packets since the FS mode has a restriction on the packet size in bulk mode as 64 bytes.

Regards
Amit

Hi again Amit,

Sorry for my late reply.

I am using an RTOS to run my software and was using the IDLE task to handle USB communication.

void vApplicationIdleHook( void )
{
	while(1){
		USB0DeviceIntHandler();
		portYIELD();
	}
}

I am doing this because i have a timed task that cannot be interrupted while it is running. the task takes a maximum of ~1.8ms so i didn't think this would be an issue, it seems that when the host wants to initiate a transaction while the USB controller is in "some" state (where the previous state was not yet completely handled??? maybe the USB library has some time critical code?) it sends a stall.

After removing this idle task and moving the USB handling to the interrupt as described in the docs It seems the issue has disappeared, for now.... This happened to me before so i will have to wait and see....

Thanks for your support,

Fransisco

Hello Fransisco

Just calling the interrupt handler in a continuous task does not seem to be appropriate. The interrupt is for getting the CPU attention. If the timed task cannot be interrupted then it must be prioritized over the USB Interrupt.

Regards
Amit