FIFO buffer sometimes filled with "CD", then sets of good data

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
bob_tipton
Level 1
Level 1
First solution authored First reply posted First question asked

I'm using an FX2LP to receive images from a camera over an isochronous endpoint as AUTOIN.  When I look at the USB packets I'm receiving, I'll receive one good packet with actual data, then 1 or more packets completely populated by "CD" in hex.  I'm wondering if this value indicates something about the state of the FIFO buffer?  The device transmits data correctly using Bulk transfers, but we need isochronous to handle the latency.

My endpoint description:

;; Endpoint 2 Descriptor, high speed
db DSCR_ENDPNT_LEN ;; Descriptor length
db DSCR_ENDPNT ;; Descriptor type
db 82H ;; Bit 7: 1 = in, 0 = out, bits 3..0 = endpoint #
db ET_ISO ;; Endpoint type
db 00H ;; Maximum packet size, LSB
db 14H ;; Maximum packet size, MSB
db 01H ;; Polling interval in milliseconds

After the image sensor is enabled, I arm the FIFO as below:

FIFORESET = 0x80; // NAK all transfers to avoid race conditions
SYNCDELAY;
FIFORESET = 0x82; // Reset EP2 flags & bytes counts to default
SYNCDELAY;

FIFORESET = 0x00; // Restore normal operation
SYNCDELAY;

EP2FIFOCFG = 0x08; // "1000" = 3:Auto commit IN packets, 2: do not allow zero length IN packets, 0: bytewide
SYNCDELAY;
EP4FIFOCFG = 0x00;
SYNCDELAY;

EP6FIFOCFG = 0x00;
SYNCDELAY;

EP8FIFOCFG = 0x00;
SYNCDELAY;

EP0BCH = 0;
EP0BCL = 0;

0 Likes
1 Solution

I'm using ISO.  After connecting a hardware-based USB protocol analyzer to the device, I now see that the blocks of "CD" data weren't actually coming over the wire, but were just my initialized buffers that I'd passed to CyAPI without being filled.  After more research, I believe the issue is that I was trying to send 2 microframes, but with auto adjust active and an EP2AUTOINLEN of 960 bytes instead of 1024.  I'm working to switch to 1024 byte packets.

View solution in original post

0 Likes
6 Replies
MallikaK_22
Moderator
Moderator
Moderator
50 likes received 750 replies posted 250 solutions authored

Hi,

Could you please share the USB analyzer traces?

Please also check the following KBA.

Regards,

Mallika

0 Likes

Just a ping because my original reply didn't post as a reply to your message.

0 Likes
lock attach
Attachments are accessible only for community members.
bob_tipton
Level 1
Level 1
First solution authored First reply posted First question asked

I wasn't sure how much data you wanted, but the first packet is pretty indicative of the data.  I've attached the raw data from the first packet, and here's the output from the URB view.  The buffers are setup as 1024 bytes, but will commit with as few as 960, since that's the horizontal resolution of the image sensor I'm using.  In the attached data file, you'll see 960 bytes of good data, then a large block of CD's, then another 960 bytes of good data.  I wasn't able to open the KBA link - I got a Salesforce single sign-on error.

000151: Isochronous Transfer (UP), 2021-09-28 11:19:41.6976414 +0.0035261. (1. Device: TMVG) Status: 0x00000000
Pipe Handle: 0x5c9f6840 (Endpoint Address: 0x82)
Get 0x1a40 bytes from the device
Start Frame: 45744029, Number of packets: 8, Error Count: 0, Start Transfer ASAP

Transfer Packet 0: Offset: 0x0, Length: 0x3c0, Status: 0x0
Transfer Packet 1: Offset: 0xc00, Length: 0x3c0, Status: 0x0
Transfer Packet 2: Offset: 0x1800, Length: 0x3c0, Status: 0x0
Transfer Packet 3: Offset: 0x2400, Length: 0x3c0, Status: 0x0
Transfer Packet 4: Offset: 0x3000, Length: 0x0, Status: 0x0
Transfer Packet 5: Offset: 0x3c00, Length: 0x3c0, Status: 0x0
Transfer Packet 6: Offset: 0x4800, Length: 0x3c0, Status: 0x0
Transfer Packet 7: Offset: 0x5400, Length: 0x3c0, Status: 0x0
000152: Isochronous Transfer (DOWN), 2021-09-28 11:19:41.6977561 +0.0001147 (1. Device: TMVG)
Pipe Handle: 0x5c9f6840 (Endpoint Address: 0x82)
Get from the device
Start Frame: 45744037, Number of packets: 8, Error Count: 0, Start Transfer ASAP

 

000153: Isochronous Transfer (UP), 2021-09-28 11:19:41.6985277 +0.0007716. (1. Device: TMVG) Status: 0x00000000
Pipe Handle: 0x5c9f6840 (Endpoint Address: 0x82)
Get 0xf00 bytes from the device
Start Frame: 45744030, Number of packets: 8, Error Count: 0, Start Transfer ASAP

Transfer Packet 0: Offset: 0x0, Length: 0x0, Status: 0x0
Transfer Packet 1: Offset: 0xc00, Length: 0x3c0, Status: 0x0
Transfer Packet 2: Offset: 0x1800, Length: 0x3c0, Status: 0x0
Transfer Packet 3: Offset: 0x2400, Length: 0x0, Status: 0x0
Transfer Packet 4: Offset: 0x3000, Length: 0x0, Status: 0x0
Transfer Packet 5: Offset: 0x3c00, Length: 0x3c0, Status: 0x0
Transfer Packet 6: Offset: 0x4800, Length: 0x0, Status: 0x0
Transfer Packet 7: Offset: 0x5400, Length: 0x3c0, Status: 0x0

0 Likes

Some additional information from testing today - if I reduce the number of packets per micro-frame to 1 instead of 3, then I only get the "CD" values for the 64 bytes beyond the minimum packet size of 960.

0 Likes
MallikaK_22
Moderator
Moderator
Moderator
50 likes received 750 replies posted 250 solutions authored

Hi,

I'm not clear on a few things. Are you currently testing with BULK or ISO?

Can you also try configuring the buffer to 512 bytes?

Please share the firmware source if not confidential? Also, please share the USB analyzer log file and not screenshots.

 

 

0 Likes

I'm using ISO.  After connecting a hardware-based USB protocol analyzer to the device, I now see that the blocks of "CD" data weren't actually coming over the wire, but were just my initialized buffers that I'd passed to CyAPI without being filled.  After more research, I believe the issue is that I was trying to send 2 microframes, but with auto adjust active and an EP2AUTOINLEN of 960 bytes instead of 1024.  I'm working to switch to 1024 byte packets.

0 Likes