DMA Manual vs DMA Auto

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

cross mob
KePa_4784036
Level 3
Level 3
First like given First solution authored 25 sign-ins

Hi,

I'm working on a project that uses a GPIF II Interface (connected to an FPGA) and a USB peripheral. I'm using the slave FIFO example (slfifosync) which is already really well documented. The only big things we changed are the DMA Channels to be Auto instead of Manual, the size (4k bytes) of the DMA buffers, the number of DMA buffers (2 with U2P, 16 with P2U) and we added some commands in the main thread function and other places to handle control transfers (coming from USB). Everything is working fine here.

Now we are at a point where we want to add some headers/footers directly into the Cypress Chip (CyUSB3) to repackage our messages coming from USB. So we changed the U2P DMA channel to Manual to begin with and checked if the bypass of the Manual instead of Auto would work. We added the "prod" signal and the callback as it was already in the initial slave FIFO example. But now, it seems like some commands sent from USB are well received and well responded but some aren't. Since I have a P2U Auto and a U2P Manual in this example, I'm wondering if there's some problems that can occur or if I'm missing something with the interrupt priority with the main CPU thread and the GPIF II.

Thanks in advance,

Keven

0 Likes
1 Solution

Hello Keven,

From the above description, i understand that your end application is as following:

1. FX3 will be idle (no data transfers going on)

2. Host PC will send a command over bulk endpoint

3. FX3 will receive the command, parse it and send some (hardcoded) data to the FPGA

Apart from this, there would be no ongoing data transfers going on between the host and the FPGA other than this. Please confirm.

If this is the case, please do the following:

1.) Modify the channels between U2P and P2U to make them between UIB to CPU (manual) and CPU to PIB (manual) - This will make the CPU intervention possible to decode the command from USB.

2.) The host can send a command to FX3 over the USB endpoint.

3.) The CPU will receive the incoming buffer (containing the command) and you can parse the buffer and send the hardcoded data (already present in the firmware) to the PIB block.

Regards,

Yashwant

View solution in original post

0 Likes
10 Replies
KePa_4784036
Level 3
Level 3
First like given First solution authored 25 sign-ins

I think this thread (CYUSB3014 freezes during Slave FIFO transfer​) might have some similarities with what I'm facing. Checking it out

0 Likes

Hello,

Can you please let us know the following to understand the issue better:

1. What exactly do you mean by "commands"? Can you please elaborate what are these commands and how are they handled by FX3?

2. Are the data transfers dependent on these commands? If not, are they happening properly?

3. From the following statement in your problem description,

"it seems like some commands sent from USB are well received and well responded but some aren't"

Do you mean to say that even after one command fails, the next can be successful? Or is it like once a command fails, everything fails?

4. Can you please share the UART debug logs for us to get more details on this issue?

It would be great if you can share the firmware project here so that we can have a look at it to debug the issue.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes
lock attach
Attachments are accessible only for community members.

1. What exactly do you mean by "commands"? Can you please elaborate what are these commands and how are they handled by FX3?

The "commands" are the messages coming from USB. The FX3 forwards the messages to the FPGA.

2. Are the data transfers dependent on these commands? If not, are they happening properly?

Yes, for example, I send a message to retrieve a version to the FPGA and it responds me with the right answer. There is a whole initialization process (get version number, read EEPROM, etc) before we get to the real deal which is the acquisition of a sensor connected to the FPGA at a fast acquisition rate. So far, my problem is happening at the initialization part. I did more debugging on my end, and I found that sending the "get version" command works for like 4/5 iterations (I get the response) and stops responding to any request after.

3. From the following statement in your problem description,

"it seems like some commands sent from USB are well received and well responded but some aren't"

Do you mean to say that even after one command fails, the next can be successful? Or is it like once a command fails, everything fails?

Since I tried sending the same command over and over, it doesn't seem like the bug is command dependant. Yes, when a command fails, everything seems to fail.

4. Can you please share the UART debug logs for us to get more details on this issue?

With the first iteration of the board we developped, there is no UART support yet so I can't provide UART logs unfortunately. My next step is to debug with messages through USB

It would be great if you can share the firmware project here so that we can have a look at it to debug the issue.

Perfect, I will link it.

N.B. I forgot to mention in my initial question that we also changed the way the driver installation is done. Since our software had a whole USB communication already well implemented (using libusb), we didn't want to make an "exception" code to handle Cypress devices. So we added the descriptors needed for an automatic WinUSB driver installation instead of CyUSB.

Thank you,

Keven

0 Likes

Hello Keven,

To rule out the possibility of some driver issues, can you please try doing the same experiment as above with the cypress provided CyUSB3 driver and share your findings?

After taking a look at the firmware, I don't see any particular point in code that can be causing the issue.

Also, can you let me know if you have made any changes to the GPIF state machine?


Regards,
Yashwant

0 Likes

To rule out the possibility of some driver issues, can you please try doing the same experiment as above with the cypress provided CyUSB3 driver and share your findings?

I tried to run my application with the CyAPI library (CyUSB3 driver instead of WinUSB) and I have the same problems. Not much to say on that.

Also, can you let me know if you have made any changes to the GPIF state machine?

Yes, we simplified it by removing 2 states from the original sm (ZLP & DSS_STATE) . Also, some signals have been removed/changed but seems to be well handled by our FPGA.

Unfortunately, I might take a break from this issue since there is some other things we wanted to do with the chip that might be impossible anyway. I want to take a shot for a sub-question but let me know if I should create another thread for it and I'll do.

From my initial issue I stated  :

Now we are at a point where we want to add some headers/footers directly into the Cypress Chip [...]

This statement was right but now it changed a bit. We would like to transform the reception of a USB message into multiple FPGA commands through the Cypress Chip. From my research, it seems like there is no real way to do it. We also don't want to use "bad ways" of doing it like resetting a DMA channel between sendings.

Is there any way I could achieve what I'm trying to do?

Thank you,

Keven

0 Likes

Hello Keven,

"We would like to transform the reception of a USB message into multiple FPGA commands through the Cypress Chip. From my research, it seems like there is no real way to do it."

=> Can you please further elaborate your requirement?


Is it like you need to split one transaction and then send?

Or is it something else?

Please clarify.

Regards,Yashwant

0 Likes

Can you please further elaborate your requirement?


Is it like you need to split one transaction and then send?

Or is it something else?

It's not a split. In the Cypress Chip, we want to get the USB message, decode it and initiate more than one Cypress->FPGA transfers. The number of transfers will depend of which message we decoded from USB (might be 2, 3, 4, 5 or 6 transfers) :

USB -----> Cypress -----> FPGA

                                -----> FPGA

                                -----> FPGA

                                -----> FPGA

Hope I made it clearer.

Good day,

Keven

0 Likes

Hello Keven,

Can you please confirm the following information:

1.) Will the USB message that is mentioned above be coming over a control endpoint or bulk endpoint?

2.) Also, after decoding the USB message, you mention that the FX3 should initiate more than one Cypress -> FPGA transfers. So:

     a. Would these transfers need to be performed at a time (parallelly) or one after the current transfer finishes (sequentially)?

     b. Where would the data for these transfers be coming from? Would it be coming from the host or is the data coded in the firmware or does      it come from some other interface (SPI or I2C) and needs to be transferred to FPGA?

Regards,
Yashwant

0 Likes

1.) Will the USB message that is mentioned above be coming over a control endpoint or bulk endpoint?

Bulk endpoint

2.) Also, after decoding the USB message, you mention that the FX3 should initiate more than one Cypress -> FPGA transfers. So:

     a. Would these transfers need to be performed at a time (parallelly) or one after the current transfer finishes (sequentially)?

     b. Where would the data for these transfers be coming from? Would it be coming from the host or is the data coded in the firmware or does      it come from some other interface (SPI or I2C) and needs to be transferred to FPGA?

The transfers would be sequentially and the data would be coded by the firmware (Cypress chip)

Thank you,

Keven

0 Likes

Hello Keven,

From the above description, i understand that your end application is as following:

1. FX3 will be idle (no data transfers going on)

2. Host PC will send a command over bulk endpoint

3. FX3 will receive the command, parse it and send some (hardcoded) data to the FPGA

Apart from this, there would be no ongoing data transfers going on between the host and the FPGA other than this. Please confirm.

If this is the case, please do the following:

1.) Modify the channels between U2P and P2U to make them between UIB to CPU (manual) and CPU to PIB (manual) - This will make the CPU intervention possible to decode the command from USB.

2.) The host can send a command to FX3 over the USB endpoint.

3.) The CPU will receive the incoming buffer (containing the command) and you can parse the buffer and send the hardcoded data (already present in the firmware) to the PIB block.

Regards,

Yashwant

0 Likes