cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

jl46
Contributor

Hello,

I've previously inquired in this forum regarding GPIO sampling synchronous to some other signals with the following timing diagram:

jl46_0-1626159625638.png

Luckily, someone sent an example firmware (firmware code + GPIF state machine code) which I'm currently using to fully understand and implement the desired mechanism on my board. I just have some questions because there are some items that aren't clear to me even now:

1)  I tried getting data using control center and when using one endpoint (0x82), i get a simple loopback. On the other hand, when I use the other endpoint (0x81), I get the following results:

jl46_1-1626160592460.png

I'm unsure of how to make sense of the received data because based on the timing diagram, I am expecting a 32-bit / 4 byte data.

2) I tried using the firmware and unlike the previous firmware codes I've used, it seems that I'm able to use "transfer IN" even without doing a "transfer OUT". How can I make sure that the data I'm receiving is correct or updated? Because the data might be a duplicate or incorrect.

As of now, these are some things that I need clarification on with regards to the GPIF. Attached here are the files sent to me by one of the engineers from this forum who initially responded to my inquiry.

Thank you for any help you might extend.

 

Regards,

jl46



0 Likes
1 Solution
AliAsgar
Moderator
Moderator

Hi jl46,

Please pull up all the data lines DQ[0:7] and then try to do the bulk IN transfer. Kindly let us know the results.

Best Regards,
AliAsgar

View solution in original post

0 Likes
24 Replies
AliAsgar
Moderator
Moderator

Hi jl46,

1. Could you let us know the timing diagram and the state of pins DQ[0:7] , when the BULK in transfer was done?

2. Could you please elaborate more on the 2nd question?

Best Regards,
AliAsgar

0 Likes
jl46
Contributor

Hi AliAsgar,

1) How can I check this? The scope that I have only has 2 channels so it's not enough to cover DQ[0:7]. Or can I check this somewhere else i.e., GPIF designer etc.

2) When I transfer IN on the 0x81 endpoint, I'm receiving the data I posted initially from control center. I assumed initially that the received data from control center are the bits sampled by GPIF (which is possibly why most data is only either 1 or 0) so I analyze 32 data points at a time and they don't seem to match the expected bit stream (i.e., expecting 0x017EA5E0 / 0000 0001 0111 1110 1010 0101 1110 0000 but receiving something different)

 

Thanks,

jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

Please pull up all the data lines DQ[0:7] and then try to do the bulk IN transfer. Kindly let us know the results.

Best Regards,
AliAsgar

View solution in original post

0 Likes
jl46
Contributor

Hi AliAsgar,

By pull-up do you mean to connect them to logic HIGH level i.e., 3.3V? 

Is there a reference for the GPIF data arrangement so that I can at least know where to start in terms of understanding the data sequence received from control center i.e. bits 0, 8, 15... is from DQ[0] etc.

 

Thanks,

jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

I connected DQ0 - DQ7 (GPIO0 to GPIO7) to high logic and then performed the IN transfer in control center and this is what I'm getting:

jl46_0-1626305990598.png

 

jl46_1-1626306012853.png

The result is all 0xFF when the GPIOs are connected to HIGH logic. After one IN transfer, I tried alternating the GPIOs to 1 and 0 (i.e. GPIO0 = 1, GPIO1 = 0, GPIO2 = 1 ...) and it took 7 IN transfers for the data to change from 0xFF's to 0x55's. I then changed all GPIOs to 0 and again it took 7 IN transfers before the data turned to 0x00's.

The clock going into the PCLK pin is 6.25MHz:

jl46_2-1626306905728.png

The trigger signal going into CTL0 is 195.313kHz:

jl46_3-1626307008090.png

The sampling should start when CTL0 goes to a negative edge and the GPIO0 - 7 will be sampled during negative edge of PCLK for 32 times which is how the state machine is defined when I double checked in GPIF designer.

Thanks,

jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

After doing some tests, I was able to decipher the data sequence:

received byte (in binary): XXXX XXXX
from left to right: GPIO 7, 6 ,5, 4, 3 ,2 ,1 ,0

so if a received byte is 0xA3 (1010 0011), this means that:
GPIO7: 1
GPIO6: 0
GPIO5: 1
GPIO4: 0
GPIO3: 0
GPIO2: 0
GPIO1: 1
GPIO0: 1

This was consistent for all the different DQ0 to DQ7 logic levels combination that I tried. I was wondering if there's a way to parse or rearrange the data because one data point (based on the timing diagram) is 32 bits and looking at the IN transfer data of 1024 bytes, it seems that this would only amount to around 32 data points.

Also, why does it take 7 IN transfers for the updated data to be received? As per testing, when I change the GPIO level combinations for DQ0 to DQ7, it takes 7 IN transfers before the received data reflects the new combination.

Thanks,
jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

1. Inside the state1 of your GPIF state machine, double click on state1 and uncheck the option where it shows "Repeat actions until next transition".

2. In the firmware, allocate just 32B instead of 32KB for the DMA buffer size.

Best Regards,
AliAsgar

0 Likes
jl46
Contributor

Hi AliAsgar,

I just saw today that the GPIF state diagram loaded with the firmware folder doesn't match the one in the jl46.cysdn folder and so I created a new copy and just replaced the continuous_read.cysdn with the jl46.cysdn. I also unchecked the "Repeat actions until next transition" option in the jl46.cysdn within the new copy. Are there any steps that I'm missing to make sure that the jl46 GPIF state diagram is properly linked to the firmware?

As a test, I connected one DOUT channel, DCLK, and DRDY from my device to the  appropriate FX3 evaluation board pins. For GPIO1 to 7, I just pulled them LOW so that the bytes received would only be 0 or 1, representing the logic level received from the DOUT channel of my device and this is what I'm getting:

jl46_0-1626408982555.png

 

jl46_1-1626409011160.png

Looking at the data initially, I don't see a pattern i.e. some bytes from certain rows should be 1 etc., which makes me think that the data isn't being captured properly or that there's something else that I might be missing. 

Looking at the GPIF file in jl46.cysdn, it seems that the interface is properly defined:
-DRDY negative edge triggered (!DRDY goes into next state)
-DCLK negative edge triggered.
-8 bits minimum, only 4 bits needed.
-IN_DATA repeats for 32 times since it needs 32 bits to reconstruct 1 data point.

please let me know what else might be missing because for static testing (changing GPIO logic level combinations) the firmware seems to be working but when using actual signals from my device, I can't seem to get correct data. Let me know also if there's anything needed from my end.

Thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

I also tried looking at the timing implementation in GPIF designer and this is what I got:

jl46_0-1626412343309.png

If you can see on the upper portion of the timing window, we can see the time period it takes for STATE0 and STATE1. If I understand it correctly, this means that STATE1 begins after some time elapsed after STATE0 which is one probable reason why the dat I'm receiving seems incorrect.

Am I correct with my understanding? If so, is there a way to solve this so that the sampling begins as soon as DRDY goes negative edge (STATE0 to STATE1 immediately).

 

thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

I tried changing the CY_FX_DMA_BUF_SIZE variable from 32768 to 32 and instead of 7 transfers, it only took 5 transfers. The number of data sent is also reduced from a previous of 1024 bytes in one IN transfer, it's now just 32. Even with the reduced number of data, the received data doesn't respond immediately to changes.

thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

While looking at the documentation, I saw a recommendation there regarding the connection of the GPIF pins to external hardware:

jl46_0-1626675653154.png


In my current setup, I'm only using connecting wires to connect the external hardware to the FX3 evaluation board. Is this a possible problem with my setup? Do I need to follow the recommendation and add 22 Ohm resistors before connecting to the FX3 GPIF pins?

I've tried supplying external digital stream to GPIO0 of FX3 and it seems to be responding or capturing properly:

1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1
1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1
1 0 0 0 0 1 1 1 0 0 0 0 1 1 1 1
0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
 
1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0
1 1 0 0 1 0 0 1 1 0 0 1 1 0 0 1
1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1
1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1


From the results, the repetitive nature of the clock signal is somehow captured and I did the tests for different CLOCK frequencies and duty cycles and it seems to be captured properly, unlike when I connect the stream from the actual hardware I'm using.

please advise if the current setup of only using connecting wires is feasible for the GPIF approach so that I can make changes accordingly and as soon as possible.

 

Thanks,
jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

1. What output were you expecting when you had connected the signals to your device? and  What kind of output did you receive?

2. Could you somehow try giving a LOGIC_ONE (HIGH) output to the 8 DQ signals from your device and check the output at the control center?

3.  Could you share with us the interface timings when the device is connected to FX3.

To obtain GPIF sampled output only when required, you could use a vendor command. When GPIF sampling is expected,  vendor command can be sent to FX3. In the firmware, you could commit the buffers to the USB side only when this vendor command is received and discard otherwise.

Best Regards,
AliAsgar

0 Likes
jl46
Contributor

Hi AliAsgar,

1) I tried pulling GPIO1  -7 LOW while feeding the digital output from the device to GPIO0. That way, the logic level sampled from GPIO0 will be reflected in the received bytes (either 1's or 0's only). 

I'm expecting a certain pattern every 32 bytes (i.e. bits 31 to  24 should be 0, bit 23 to 21 = 101 etc.) so I should be seeing this every 32 bytes but I don't seem to be getting this response. I even tried looking at the bytes in reverse but this doesn't seem to be the case as well. 

2) I tried inputting logic 1 to all GPIOs 0 to 7 and this is what I'm getting in control center:

jl46_0-1626780966534.png


3) 

jl46_1-1626781638815.png

Orange: DCLK, Violet: DRDY

jl46_2-1626781935809.png

Violet: DRDY, Orange: GPIO0 connected to device.

The digital stream is somewhat constant with some variations but the pattern is more or less something like that from the scope shot above. 

As of now, I'm just using the firmware I received from this forum in my past inquiry as is. I just perform an IN transfer on endpoint 0x81 to receive the data. I haven't tried modifying the firmware as I'm still trying to understand how the GPIF function works in the firmware example.

Thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

I tried changing the endianness of the jl46.cysdn GPIF project from Little to Big Endian. I built the project and copied the updated cyfxgpif2config header file into the GpiftoUsb firmware folder. When I uploaded the img file and captured data, all I get are 0's:

jl46_0-1626826527554.png

Even when I changed back to Little Endian and used that header file, I'm still getting all 0's. Am I missing something when integrating the generated header file from the GPIF designer? 

Thanks,
jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

The integration of GPIF header file is correct.

Could you get the interface signals between the GPIF and your device using a logic analyser ?

Best Regards,
AliAsgar

0 Likes
jl46
Contributor

Hello AliAsgar,

I've modified the state machine to do some tests. I also will have to look back at the documentation of the device I'm trying to interface as there might be some things I've overlooked.

Right now, I'm aware of how the sampled logic level from DQx (0 to 7 in my case) is parsed onto the data read from control center. I was wondering if there's a way that the GPIF capture is triggered only when I send a certain command? 

With my modified state machine, it seems that the capture is continuous and I would like to have the capture begin only when I send a certain command over USB to the FX3.

 

thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

In the original state machine, what does the option "Repeat actions until next transition" mean:

jl46_0-1627363496867.png

When I had the box unchecked, there were a lot of zeros (0x00) in the received data from control center but when I had this checked, the data stream had lesser 0's:

jl46_1-1627363655116.png

From the state machine (original), after START it goes to STATE0 and goes to STATE1 when DRDY goes love and performs the IN_DATA 32 times (negative edge of PCLK) and then goes to STATE0 once DRDY goes HIGH and then repeats the process. Do I understand the state transitions correctly? 

thanks,
jl46



0 Likes
AliAsgar
Moderator
Moderator

Hi jl46, 

Your understanding of state machine is correct for when "Repeat actions until next transition" is unchecked. When this field is checked, till DRDY is not HIGH again, the GPIF will go on sampling the pins. That is the reason we had recommended to uncheck the field in the previous response.

Vendor Commands along with a MANUAL channel could be used for to receive selective sampled GPIF signals at the USB side.

Best Regards,
AliAsgar 

0 Likes
jl46
Contributor

Hi AliAsgar,

I just modified the GPIF state machine I sent here to match the operation of the firmware only version that I had initially working. I also added in the vendor command option to start and stop the GPIF state machine for a controlled sampling environment.

I just have a question. Would the firmware and state machine, which works on my FX3 eval board, work on a board that has a CYUSB3014-BZXC. The firmware + state machine is working with my external board + FX3 eval board but I have a similar one but has a CYUSB3014-BZXC with pins rerouted to match that of my FX3 eval board setup that has problems doing transfers. I want to know if this is a factor that I need to consider in my testing.

thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

Just a correction, the part that's in one of my other boards is CYUSB3011-BZXC compared to the CYUSB3014-BZXI in the evaluation board. I know that the BZXI / C only pertains to operating temperature. 

Since I developed and tested the GPIF state machine and firmware using the CYUSB3014 in the FX3 eval board, is it possible that this would cause problems when I upload it to the board with the CYUSB3011-BZXC? I've tried doing so and when I do data transfer from control center, I encounter error code 997 which I don't usually experience when testing with the FX3 eval board. If it indeed causes problem/s, is there any way I can develop a similar firmware + state machine that's compatible with the CYUSB3011? 

 

Thanks,
jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

Mainly there is only memory mapping difference between CYUSB3011 and CYUSB3014. But as the buffer size in the firmware is less, this should not be a problem.
Hence, the firmware and state machine should be compatible with CYUSB3011.

Could you send the debugPrints when the error is received?

Best Regards,
AliAsgar

0 Likes
jl46
Contributor

Hi AliAsgar,

The error is in control center when doing IN or OUT transfers. I removed the debug prints in the code and the UART part since I'm mostly concerned with the USB transfer and GPIF. When the number of bytes I transfer OUT or IN is 4 bytes or less, there seems to be nor problem. But when the bytes are 5 or more, i have problem doing IN transfer:

jl46_0-1628247553106.jpeg

 



Also, is it really possible to use the other GPIF pins i.e., GPIO4,5,6,7 etc. as typical GPIOs even when GPIF enabled? In my case, I use GPIO0 to 3, 16 (PCLK), 17 (DRDY) for capturing but I want to use the other pins as typical GPIOs as well for other connected pins.

The .img file of our old firmware is 133KB while the modified GPIF firmware that includes vendor commands is 153KB. DOes the 20KB difference make an impact on the compatibility of this new firmware with the CYUSB3011? What do we need to check to make sure that the firmware would be matched to the 3011?

thanks,
jl46

0 Likes
jl46
Contributor

Hi AliAsgar,

Upon checking, it seems that my modified firmware (with GPIO initialization and SPI functionalities) is working properly when GPIOs 4-7, and 19 are freed up or not connected to anything. This would require me to reroute some pins in order to have the boards working. Is there any note or explanation on the datasheet / reference manual etc. as to why this is? 

And also about the firmware for 3011, is there any way we can check the compatibility of the GPIF firmware that works on the 3014 with the 3011? Like I mentioned in the previous comment, there seems to be a 20KB difference between the old firmware I'm using and the now I modified recently (GPIF) and I'd like to know what to look for or check to see if the firmware requirements would match the 3011.

Thanks,
jl46

0 Likes
AliAsgar
Moderator
Moderator

Hi jl46,

Could you send us the debugPrints as we would like to know which API is failing during the error.

Also, CYSUB3011 has a 256KB SRAM. So the firmware image size should not be more than 128KB. Kindly refer to fx3_256k.ld for the memory map of CYUSB3011.

Best Regards,
AliAsgar

 

0 Likes