slave fifo, got an Error code 64 for every new buffer sent.

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

cross mob
LuCu_4098176
Level 3
Level 3

Hello,

Using the original slave fifo code provided (with only some vendor commands added)

I Write some data on the slave fifo terminate last word with "pktend" (signals look perfect and exactly as in the slave fifo write sequence diagram)

Then I see the on the serial port debug the "buffers sent" passing from 0 to 1. So I must be writing it well.

However when I try to bulk receive I got 0 bytes.

Looking closer when message passes from "buffers sent: 0" to "buffers sent: 1" there is one error:

"CyU3PDmaChannelCommitBuffer failed, Error code = 64"

Since I did not touch anything on the slave fifo example provided what am I doing wrong ?

I added a few vendor commands that write some bits on gpio pins and changed the define from 32bit to 16bit wide, all the rest is untouched.

(running lower clock, 50MHz or 25MHz, does not help).

What am I missing ?

Any help please.

Luis c.

0 Likes
1 Solution

Dear Yashwant,

Lets close this thread as I discovered that on a windows machine the USB-Control-Center

receives fine. So there is something wrong with the CyUSB-Linux program or else.

I will open a question about this on the forum, others may have experienced this before.

Thanks.

Luis C.

View solution in original post

0 Likes
9 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

Hello Luis,

"I added a few vendor commands that write some bits on gpio pins and changed the define from 32bit to 16bit wide, all the rest is untouched."

--> Can you please share the way that you made the modification about the 32-bit to 16-bit?

To change the bus width to 16-bit, please make sure you have done the following:

1.) Change the value of the macro to #define CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT (0) in cyfxslfifosync.h in the project.

         This will change the clock frequency from 403.2MHz to 384MHz for the 16-Bit interface.

2.) Modify the slavefifo state machine's bus width to 16-Bit as shown below:

pastedImage_4.png

To save and generate the new modified header file, click on Build -> Build Settings... -> Change the Output Location: to the project workspace location and build the project.

Please confirm that the new header file is generated successfully, check for the date and time of the generated cyfxgpif2config.h and make sure it's updated to the date and time of building the header file.

3.) Refresh the project and then re-build it again and program the device with the new image file.

4.) Please check if you face the error again.

Please do the following and let me know the results.

Regards,

Yashwant

0 Likes

Dear Yashwant,

Thanks for your detailed reply.

The only thing I did was to change the #define CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT (0)

accordingly.

I did not modified the slavefifo state machine (I did not knew it was necessary, I assumed the #define above did it all).

But now I have a problem... I'm on linux and the GPIF designer does not run here.

Is there anywhere a "cyfxgpif2config.h" already configured to 16 bit, the same way/behavior as the original is for 32 bit ?

or are the changes possible to make by hand, since I don't want to change anything else but the bus width ?

Let me know.

Many thanks.

Luis C.

0 Likes

Hello Luis,

Apologies. I checked the config.h file now and see that the macro can change the data bus as to 16-bit.

Your understanding of the macro is correct and it will change the bus width to 16-bit as well when you change

#define CY_FX_SLFIFO_GPIF_16_32BIT_CONF_SELECT (0)

Can you please share the UART debug logs?


Regards,
Yashwant

0 Likes

Here goes.

...

Data tracker: buffers received: 0, buffers sent: 0.

Data tracker: buffers received: 0, buffers sent: 0.

Data tracker: buffers received: 0, buffers sent: 0.

CyU3PDmaChannelCommitBuffer failed, Error code = 64

Data tracker: buffers received: 0, buffers sent: 1.

Data tracker: buffers received: 0, buffers sent: 1.

Data tracker: buffers received: 0, buffers sent: 1.

Data tracker: buffers received: 0, buffers sent: 1.

...

Thanks.

(all cool, no need to apologize)

Luis C.

0 Likes

Hello Luis,

As shown in AN65974, the master should follow the following to ensure a short packet commit is done successfully:

pastedImage_0.png

"However when I try to bulk receive I got 0 bytes."

--> Can you please share a snapshot of the control center for the same?

The error code = 64 corresponds to "0x40" which is as follows:

    CY_U3P_ERROR_BAD_ARGUMENT = 0x40,   /**< One or more parameters to a function are invalid. */

Regards,

Yashwant

0 Likes

Hello Yashwant,

Thanks for your reply.

I read that and I though it was clear but now that you point it I become to have a doubt about that sentence from the AN65974.

I use indeed a pktend at the last word written.

I do a burst write,  CS goes low then WR goes low and stay low all the time, while data is being clocked in and at the last word

I assert PKTEND to tell that this packet is over (WR low all the time, from first word to last word) then WR goes high and CS goes high.

This is what I have implemented.

( I know that the asserting pktend without wr=0 sends a zero lenght packet. but I'm not doing that.)

--> Can you please share a snapshot of the control center for the same?

Nothing to show really. I hit the receive button and the "data in" statistics

display "0" and the "data in" window stays blank.

---

Can you please to confirm that my burst writing sequence, as I described above, is correct ?

One question related with the above. I see on the diagrams that CS only rises to high a few clock cycles after WR become high

is this mandatory... On my design I rise WR and on the next clock I rise CS. Would this be a cause of problems ?

Many thanks.

Luis C.

0 Likes

Hello Luis,

I do a burst write,  CS goes low then WR goes low and stay low all the time, while data is being clocked in and at the last word

I assert PKTEND to tell that this packet is over (WR low all the time, from first word to last word) then WR goes high and CS goes high.

This is what I have implemented.

--> This implementation is correct and is according to the SlaveFIFO write sequence.

Nothing to show really. I hit the receive button and the "data in" statistics

display "0" and the "data in" window stays blank.

-->Can you please share the snapshot of control center window so that i can get an idea of the issue?

One question related with the above. I see on the diagrams that CS only rises to high a few clock cycles after WR become high

is this mandatory... On my design I rise WR and on the next clock I rise CS. Would this be a cause of problems ?

--> This is okay since Slave waits for both the signals to be asserted to reach the WRITE state in the state machine. This won't be an issue.

Can you please tell how much data is being sent by the master over GPIF to slave?


Also, is it possible for you to test the default 32-bit configuration of the firmware without any modifications?

Regards,
Yashwant

I do a burst write,  CS goes low then WR goes low and stay low all the time, while data is being clocked in and at the last word

I assert PKTEND to tell that this packet is over (WR low all the time, from first word to last word) then WR goes high and CS goes high.

This is what I have implemented.

0 Likes

Hello Yashwant,

Ok. here goes the scr.capture:

Screenshot at 2020-04-08 13-09-35.png

> Can you please tell how much data is being sent by the master over GPIF to slave?

I'm now sending 128 words and pktend to commit this packet.

I have tested with different lengths and result is the same.

I have tested also without pktend and send until flag_a reports full. Same result, when

a packet is ready to be committed I got the same error.

I have made an additional test that was: went to a windows machine, generate a fresh config for a slave fifo

with 16bit bus. Back in my system I rebuilt the project with that new header file. Uploaded to the FX3 (kit).

(I noticed that some numbers on the GPIF configuration were different)

Run the system and got the same error.

Then I removed all the GPIO bits from the fx3 and commented all my code that was dealing with the

vendor commands and instead of starting a FPGA into FX3 using a vendor command and GPIO I have

hooked up an Arduino to do the FPGA commands.

The error disappears (so apparently I messing up with something... but I could not find where).

Still I cannot transfer anything into the CY_USB aplication when I hit the "receive" button.

keeps saying 0 bits and empty rx window.

> Also, is it possible for you to test the default 32-bit configuration of the firmware without any modifications?

I have GPIO bits configured in the former D16, to D19, Now that I removed them I may test.

So I have two problems.

1 - The error caused by the vendor commands and GPIO code.

2 - Nothing is transferred even when I comment out the code I have inserted.

for  problem 1 the relevant info info for you to have the full picture is to know what I have added.

(the functions I call only write and read GPIO bits to do a special SPI by bit-bang in software and nothing else,

that by the way is working fine)

    // lc,  Vendor request out & write spi

    else if ( (bReqType == VR_TYPE_OUT ) && (bRequest == VR_WRITE_SPI) )

    {

        CyU3PUsbGetEP0Data (sizeof (glEp0Buffer), (uint8_t *)glEp0Buffer, &wLength);

        CyU3PThreadSleep (1);                           //ack needs to get out before end of thread (may be removed if write_spi_bits take long enough)

        btarget = (uint8_t) (wValue & 0x00ff);          //target chip on lower byte

        nbits = (uint8_t) ((wValue >>8) & 0x00ff);      //nr of bits on upper byte

        write_spi_bits( btarget, nbits, glEp0Buffer);   //send bits to target chip

    }

    // lc.  Vendor request in & read spi

    else if ( (bReqType == VR_TYPE_IN ) && (bRequest == VR_READ_SPI) )

    {

        btarget = (uint8_t) (wValue & 0x00ff);          //target chip on lower byte

        nbits = (uint8_t) ((wValue >>8) & 0x00ff);      //nr of bits on upper byte

        read_spi_bits( btarget, nbits, glEp0Buffer);    //get bits from target chip

        CyU3PUsbSendEP0Data (wLength, glEp0Buffer);     //send bits over ep0

        CyU3PThreadSleep (1);                           //packet needs to get out before end of thread

     }

...

further down the code I have configured the GPIO pins in the same way the existing code.

was just copy/paste and different pin number.

---

For problem 2, with all original files and configured to 16 bit

by giving cyusb aplic. filenames to the out and in files it was possible to see the error

on a pop-up. apparently something gets transferred as the debug port counts

an increasing nr of packets being sent each time I clear up the halt condition and

hit "receive again" but always got this pop-up.

Screenshot at 2020-04-09 02-20-05.png

I am quite confused now

and running out of ideas on what to do.

If you kindly provide your help I would ask that you help me first on the transfer problem

for that I really need help. (on the GPIO and vendor commands I can go step by step and

try to figure out myself what is messing up the system)

Many Thanks.

Luis C.

0 Likes

Dear Yashwant,

Lets close this thread as I discovered that on a windows machine the USB-Control-Center

receives fine. So there is something wrong with the CyUSB-Linux program or else.

I will open a question about this on the forum, others may have experienced this before.

Thanks.

Luis C.

0 Likes