USB DATA0/DATA1

[MattInSeattle]

I'm using an MCUXpresso, SDK 2.8.3, LPC55S16 with bulk endpoints, evolved from mass storage example (but no longer  mass storage device). Using endpoints 1, 81, 2 and 82, I can transfer data all day long no problem. 

I added endpoints 3 and 83 and increased USB buffer size (USB_DEVICE_IP3511_ENDPOINT_RESERVED_BUFFER_SIZE) to 8K. Previous EPs still work fine. Descriptors show up fine in sniffer tools.

Data transfer on EP3 starts at t=0 in attached log, but after a few transfers (see 11.3mS after first), I start to see OUT with no status. So, the host re-sends in the same USB buffer (DATA1) which then gets a NYET as expected. (orphan warnings go away when the device is by itself on a hub)

So, would someone with more experience with USB mind commenting on whether nor not what I'm seeing is a problem or not? It seems that once the PC sees PING-ACK, the OUT should succeed. But it doesn't. It requires another send of the data on the same buffer (either DATA0 or DATA1) to get back a NYET. And this is pervasive in the log. Over and over it's PING-ACK, then OUT (no response), then PING-ACK, then OUT with same data (no response). After 6 of these, finally there's a NYET and it starts all over again.

In the code I'm calling USB_DeviceRecvRequest() when I am ready for another buffer, and in the callback for that I enqueue the buffer in a fifo (FreeRTOS queue) and then call USB_DeviceRecvRequest again from the callback if the fifo isn't too full. 

The most succinct question I could formulate at this point is this: Why is there no status response to an OUT after a PING-ACK? But the same OUT 10 uS later succeeds?

Thanks

[FelipeGarcia]

Hi Matt,

So you see this issue only with EP3? It is indeed strange, I think after a PING ACK the endpoint should respond with either ACK or NYET, sending same data does not seem to be expected. What I could think is that similar thing that generates the orphaned packages could be causing this issue, this packets are often seen when multiple devices are plugged into the same host controller or if you are using a hub as well.

Regards,

Felipe

[MattInSeattle]

Hi @Felipe, I had to stop working on this but I will resume again hopefully next week and report back with a conclusion if found. Thanks very much for the response. 

[MattInSeattle]

Hi @FelipeGarcia I'm back to looking at this and after two days I've isolated the problem down to the data going into the I2S FIFO. When that I2S FIFO data is all zeros, the USB works exactly as expected for hours on end and looks great on the Beagle USB480 logger. But, if the data submitted to the I2S DMA is memset to just about any value other than 0, the USB transaction is garbage. 

How can it be that buffer *contents* submitted to the I2S DMA are corrupting a USB transaction? Any guesses? Thanks in advance for any leads.

11.2.0 IDE and 2.8.2 SDK, LPC55S16, FreeRTOS

 

 

[MattInSeattle]

We have finally tracked this down. The I2S data out pin was pin 30 on the LPC55S16 100 pin package. The 16 MHz XTAL is pin 29. When the I2S was outputting all zeros, the 16 MHz crystal looked fine on a spectrum analyzer when sniffed with EMC near-field probes. When the 0x55 was being output, the 16 MHz spectrum showed a rise in skirts and a drop in amplitude, indicating jitter. In fact, it was bad enough that it could be readily seen on a scope too. 

So, non-zero data pattern on the I2S output induced jitter in the adjacent xtal pin causing a lot of packets that were ignored (presumably due to bad CRC). The Windows machine, after seeing a lot of packets that are ignored, stops sending to that endpoint after a while (USBD_STATUS_XACT_ERROR). Curiously, Windows will keep sending to other endpoints. So, if you have one enpoint that is used for lots of data traffic it will shut down rather quickly. And another endpoint that is seldom used, it will stay up.

What made this hard to track down is the Beagle USB analyzer has a clean clock and of course it is showing the packets all have the correct CRC, etc. So, it appeared that the LPC was generating a single interrupt in spite of 10 correct packets being sent. But in fact, the LPC saw errors in the first 9 of those packets, and didn't generate an interrupt.

So, if you are from the future reading this note and wondering why your USB trace appears to show packets that the LPC isn't responding to, or if you are seeing the XACT_ERROR from Windows, or severely degraded throughput, check your LPC 16 MHz clock. In the future, I'd not use a IO pin that needs to transition a lot near an XTAL pin if USB high speed is also needed. Whenever that pin is wiggling, the USB is likely struggling. In fact, I'd keep any IO away from the 16 MHz pins OR use an xtal oscillator.