cancel
Showing results for 
Search instead for 
Did you mean: 

USB Low-Full-High Speed Peripherals

zheng
New Contributor II

Hi,  The following figure 1 shows my system. The first time, I sent a request from the host, and the data written to ep6in from 8051 was correct, but I read ffffffff in the host (as shown in the red box in Figure 2). The second time, I sent the same request from the host again, and I read the correct value in the host (as shown in the basket in Figure 2). Similarly, for subsequent communications, the first reply from fx2lp is ffffff, and the correct information is returned the second time. Would you give me some advice on why?

Fig.1:

zheng_0-1635419809888.jpeg

Fig.2:

zheng_1-1635420489252.png

Best regards,

Zheng

 

0 Likes
6 Replies
MallikaK_22
Moderator
Moderator

Hi Zheng,

Could you please share the USB analyzer logs ?

Is there a difference between the bytes of data you want to transfer and the size of the endpoint buffer?

Regards,

Mallika

Mallika
0 Likes
zheng
New Contributor II

Hi  Mallika,

Thank you for your reply. The log file is uploaded.

I use EP6 as data input and EP1 as data output. As Countermeasure,After I armed the EP2 before  the arm of EP6 to the td_poll function, [ffff..] no longer appears, but I don't know why. Here is a part of my DSRC file:

db DSCR_ENDPNT_LEN ;; Descriptor length
db DSCR_ENDPNT ;; Descriptor type
db 86H ;; Endpoint number, and direction
db ET_BULK ;; Endpoint type
db 00H ;; Maximum packet size (LSB)
db 04H ;; Max packet size (MSB)
db 00H ;; Polling interval

Best regards,

Zheng

0 Likes
zheng
New Contributor II

Hi Mallika,

Because the size of ep1out is relatively small, which affects the communication performance, I changed ep1out to EP4, but the following situations occur.
1. When sending a message from the host, EP4 cannot receive data.
2. The interruption of EP4 cannot be generated
I uploaded DSCR and other files. Would you help me find the problem.

Best regards,

Zheng

0 Likes
MallikaK_22
Moderator
Moderator

Hi Zheng,

Kindly check the descriptors for full speed in your dscr file. They seem improper. 

In fifo_reset(), 0x82, 0x84, 0x86, 0x88 should be used instead of 0x02, 0x04, 0x06 and 0x08.

How is the FX2LP device enumerating on the host?

Is there any issue in the Data IN path also?

Could you please once check the firmware source for implementing FX2LP as a COM port available here: https://www.cypress.com/documentation/application-notes/an58764-implementing-virtual-com-port-using-...

 

 

Mallika
0 Likes
zheng
New Contributor II

Hi Mallika,

Thank you for your reply. I'll change the full speed setting to see if I can solve the problem.

>In fifo_reset(), 0x82, 0x84, 0x86, 0x88 should be used instead of 0x02, 0x04, 0x06 and 0x08.

In the FIFORESET part of the TD_Init(), I imitated the setting of AN66806. At the beginning, I set [fiforeset = 0x80] to activate NAK-ALL to avoid race conditions. Must bit7 of all endpoints be '1'?

>How is the FX2LP device enumerating on the host?Is there any issue in the Data IN path also?

Based on an58764, I only changed ep8in to ep6in, and can communicate successfully in both in / out directions. Because the size of ep1out is relatively small, I want to replace it with ep4out to speed up communication, but I haven't succeeded yet. The second problem is mentioned above. I have to arm endpoint twice to send correct data to the host (the first time is ffff...). Although I avoided this problem by arming an endpoint that is not actually used at first, I don't know the real reason. 

I don't know if it correctly describes my question. If you have any questions, I look forward to your reply.

Best regards,

Zheng

 

0 Likes
MallikaK_22
Moderator
Moderator

Hi Zheng,

Arming an endpoint twice is not an issue but an expected thing to do. Since your OUT endpoint is double-buffered, you need to arm it twice. 

Regards,

Mallika

Mallika
0 Likes