cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

cnlohr
New Contributor II

I have a basic setup working great with the FX3 when operating in synchronous master mode with internal clock settings.  But, my data source always has the clock running from the start, so PCLK is always receiving a clock and data.

GPIF Settings:

(Master/Slave) Either causes crash
(Synchronous)
(External Clock)

The moment the GPIF bus is loaded, the processor freezes.  Sometimes it gets as far as calling a `CYU3P_PIB_INTR_DLL_UPDATE` before freezing.  It's always after load.  I've tried springboarding into a loop of DATA_IN that doesn't actually write the data but nothing I do seems to prevent the device from freezing except discontinuing the clock.

Is there a way to suppress the PCLK pin until everything else is setup and ready to roll, like the state machine is started?  Or anything else I can do to prevent the chip from seizing up when unsolicited data is flowing in?

BTW - as soon as I switch around to internal clock writing out, everything works 100% as expected.

0 Likes
10 Replies
Rashi_Vatsa
Moderator
Moderator

Hello,

From the description, I understand that external clock and data is fed to FX3 continuously irrespective of the GPIF interface initialization. Is my understanding correct?

Please check if any of the API is failing when the freeze is seen. If possible, please share the UART debug prints and the firmware snippet (initialization of GPIF/PIB) for us to check.

Please let me know the frequency of external clock fed to FX3's PCLK. When the PCLK is fed externally, is the GPIF used in synchronous slave mode ? Please note that for GPIF slave mode, DLL should not be enabled.

Regards,
Rashi
0 Likes
cnlohr
New Contributor II

Thank you for replying, @Rashi_Vatsa 

This portion of code can be available publicly.


(1) Yes.  Data flows irrespective of GPIF initialization.  Stream constantly comes in regardless of FX3 state.

(2) No API Failures.

(3) I made a mistake about the DLL being enabled - it was, but even if I disable the DLL, the system still freezes.  Additionally, I switched to Synchronous Slave Mode.

Here is the source: https://gist.github.com/cnlohr/2e39a6201a46576f08c123a70e6bd15d

Here is the output:

��IsoSrcAppThread_Entry(...)
��In IsoSrcAppThread_Entry(...)
��Past GPIO Init
��)Setting the USB Enumeration descriptors
�MIDDLE
��PRE
��
  Connecting
�� Loading
��Registering Callback
��CyFxIsoSrcApplnInit Complete
��CyFxIsoSrcApplnInit(...) done
��STATIN
��#Starting initialization speed = 3
��#Default CyFxIsoSrcApplnStart start
��De-initializing...
��Thread Inactive
��De-initializing...
��#Starting initialization speed = 3
��#Default CyFxIsoSrcApplnStart start

 

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

Thank you for the firmware.

Could you please let me know from where is CyFxIsoSrcApplnStop API called which leads to the following print.

��#Default CyFxIsoSrcApplnStart start
��De-initializing..

Also, can you please check the return status of CyU3PGpifSMStart API when the Appstart is called the second time as shown in this print

��De-initializing...
��#Starting initialization speed = 3
��#Default CyFxIsoSrcApplnStart start

Also,  In the current code implementation, I observed that CyU3PGpifLoad is called before  CyFxIsoSrcApplnStart is called or the DMA channel is created. Please try following the code sequence as mentioned in CyFxApplnStop of gpiftousb example where CyU3PGpifDisable (CyTrue) is used and in the CyFxIsoSrcApplnStart function try calling CyU3PGpifLoad and CyU3PGpifSMStart. Please try following the above mentioned sequence and let me know if any of the API fails

Regards,
Rashi
0 Likes
cnlohr
New Contributor II

I've read your post a few times and I'm still not following.

(1) CyU3PGpifSMStart returns 0, in all situations from what I can tell.

(2) I always deinit whenever my app is starting (control message is sent to cause this) because frequently the DMA gets in a hosed state and I need to restart the GPIF bus + DMA.  That said, if I disable the de-initialization, it doesn't crash, at least for a moment.  After a few seconds, though, the system does fail, and I have no mechanism to restart it.

(3) Placing the call to CyU3PGpifLoad at the end of CyFxIsoSrcApplnStart still causes it to freeze even when CyU3PGpifDisable( CyTrue) is called.

Is there an appnote which covers the optimal startup/shutdown/restart sequence?

0 Likes
cnlohr
New Contributor II

Correction - switching around and not always disabling does not always work, it seems to sometimes work and sometimes freeze.

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

Thank you for the details

Please refer to GpiftoUSB example of the SDK for the initialization, appstart and appstop sequence.

Meanwhile, I tried to reproduce the issue with back to back FX3 kits connected. Master FX3 fed PCLK to slave even when the PIB block (slave) was not configured. But I couldn't reproduce the problem at my end.

Please let me know if  there any other signals (output from FX3) on which the data transfer is done from Master. If yes, it is recommended to configure the slave first and then configure the Master

Regards,
Rashi
0 Likes
cnlohr
New Contributor II

We are seeking other avenues to resolve the issue.  One option is to change our system around and operate solely in master mode, but we are finding that we require the ability to change the clock after the chip and GPIF bus is booted.  Will open a new issue because we are also having trouble with that tactic.

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

For the case when FX3 is in Slave mode (DLL disabled), can you please probe and let me know the frequency of PCLK fed to FX3 from  external master.

From the code that you have shared, I could understand that 0xBB vendor command is sent from host to de initialize. Please share the UART debug prints without sending this vendor command. I understand that this vendor command would not be sent when GPIF internal clock is used. Is my understanding correct?

Regards,
Rashi
0 Likes
cnlohr
New Contributor II

The command is normally sent, regardless of if the internal or external clock are used, and the external clock is 30 MHz in this case.

We have a work around currently, but I would still like to drive this to a solution if possible.   I am currently trying another uninitialization/reinitialization approach, a little closer to that in the GpiftoUSB  you mentioned.

0 Likes
Rashi_Vatsa
Moderator
Moderator

Hello,

Please let me know if changing uninitialization/reinitialization approach helped.

The command is normally sent, regardless of if the internal or external clock are used, and the external clock is 30 MHz in this case.

>> Could you please not send  the command (i.e. without re initializing) and  share the UART debug logs?

Regards,
Rashi
0 Likes