FX3, I can't recover from "Error code 64"

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

cross mob
LuCu_4098176
Level 3
Level 3

Hello,

I have an application that uses an fx3 with the slave fifo (same source code as per the example provided, with minor additions for some vendor commands,

while dma buffers and all USB stuff was left untouched).

My application works fine but occasionally (quite rare) I have an hangup and the trace on the serial debug shows:

       CyU3PDmaChannelCommitBuffer failed, Error code = 64

I would like to understand what this really means, or even more important, what can I be doing wrong that causes this.

The problem is that when this happens it get stuck with flag_A low and I cant figure out a way to get out of this state besides a full switch off

and restart all over again (which is a very inconvenient recover... this is to work on remotely placed systems).

I would like to stress that besides these rare occurrences the system can stay working well for hours without issues.

Now it getting frustrating... if I want to find the problem it insists in working well and if I decide to use it it insists to fail

(in reality this problem is lurking around since the very beginning of this project of mine...)

I don't even know where to begin... what is this error and what may be a possible cause,

any help ?

Many thanks.

Luis.

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Luis,

We are trying to find what is the root cause for your problem. That is the reason we mentioned to check the status of CyU3PDmaChannelIsValid() API.

CyU3PDmaChannelCommitBuffer() may return CY_U3P_ERROR_BAD_ARGUMENT when CyU3PDmaChannelIsValid() returns failure. So please check and let us know if this API ever returns failure when called before CyU3PDmaChannelCommitBuffer()

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
6 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Luis,

The error 64 is a CY_U3P_ERROR_BAD_ARGUMENT error.

As Flag A goes low when the error is seen, it seems that the error is caused while committing the buffer/data to USB. Please confirm if the error occurs when transfers are done from PIB to USB.

If yes, please let me know if there are any PIB errors (like CYU3P_PIB_ERR_THR0_WR_OVERRUN) seen when this error occurs. Please share the UART debug prints when this error is seen

Please try calling CyU3PDmaChannelIsValid API before calling CyU3PDmaChannelCommitBuffer API and check if CyU3PDmaChannelIsValid returns CyTrue

Regards,

Rashi

Regards,
Rashi
0 Likes

Dear Rashi

Thanks for you reply.

When the error happens a buffer has just been written from FPGA to FX3 right after 1024 bytes were written to the FX3.

The uart debug print is the following (note that I have added a counter to keep track of producer and consumer events, just to be sure what was going on)

CyU3PDmaChannelCommitBuffer failed, Error code = 64

CyU3PDmaChannelCommitBuffer failed, Error code = 64

Data tracker: buffers received: 0, buffers sent: 2 (pending 2).

Data tracker: buffers received: 0, buffers sent: 2 (pending 2).

etc....

I can flush the pending buffers, but the problem from now on is that Flag A is stuck low no matter what I do.

I have discovered that something on the PC side may be causing the buffers to fail to be committed to the USB.

Ideally this situation should not happen but maybe we can't really avoid this from happening if the software on the PC side crashes or has a bug. When all seems to be ok on the PC side all works without issues.

I know when I feed too much data it throws up error 71 but it recovers from this, but when the error 64 happens it puts FlagA low and never gets out of that state. (I have tried a lot of things without success) only off/on cures it.

My problem is simple:  the PC where the device is connected is to be operated remotely, FX3 off/on

can not be done.

Lets assume for a moment that those errors are indeed correct as the FX3 could not commit data to USB It does survive to error 71 but it stalls on error 64 as flagA is stuck low. (note that FX3 keeps responding well to vendor commands so I can dedicate a vendor command to do some sort of fifo re-initialize).

How can I programmatically in the FX3 code reset the fifo state machine and get it to a fresh new start ?

tks.

Luis

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hello Luis,

Can you please check below as mentioned in the previous comment:

Please try calling CyU3PDmaChannelIsValid API before calling CyU3PDmaChannelCommitBuffer API and check if CyU3PDmaChannelIsValid returns CyTrue

Sometimes do you see code 71 being returned from CyU3PDmaChannelCommitBuffer()?

If there are any uart debug print statements in dma callback please remove them.

Please check if CyU3PDmaChannelDestroy() is called anywhere in your firmware.

Regards,

Hemanth

Hemanth
0 Likes

Hello Hemanth,

I use the original supplied slave fifo code without any relevant modifications only a set of vendor commands were added and

a few GPIO pins used. None of the DMA, slave fifo sections of the code were touched.

I have checked and the only place where CyU3PDmaChannelDestroy() is called is at CyFxSlFifoApplnStop ().

Yes, the error 71 happened in the CyU3PDmaChannelCommitBuffer() but as I mentioned before it does not harm the system as it recovers from it quite smoothly. Furthermore when all data is flowing with produced data by the FPGA and consumed data by the PC configured properly error 71 never happens. So lets declare error 71 as solved.

For the error 64. I may add a verification of channellsvalid and only call the commit buffer if it returns valid

... at CyFxSlFifoPtoUDmaCallback(...) I can check

     if ( CyU3PDmaChannelIsValid() == CyTrue )

          status = CyU3PDmaChannelCommitBuffer(...)

          ... etc

If not valid I would not try to commit the buffer and would not get the error but the FlagA is already low (as FPGA had already filled up the buffers) so the system stalls the same !

am I missing something here ?!

Wouldn't a fresh fifo restart be a good idea ? (I would try it if I knew hot to do it )

Thanks

Luis.

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Luis,

We are trying to find what is the root cause for your problem. That is the reason we mentioned to check the status of CyU3PDmaChannelIsValid() API.

CyU3PDmaChannelCommitBuffer() may return CY_U3P_ERROR_BAD_ARGUMENT when CyU3PDmaChannelIsValid() returns failure. So please check and let us know if this API ever returns failure when called before CyU3PDmaChannelCommitBuffer()

Regards,

Hemanth

Hemanth
0 Likes

Ok, got it. I will do and let you know.

(should be easy to see if it returns false or true when the error64 happens).

Thanks.

Luis.

0 Likes