cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

JoNe_4646056
New Contributor II

Hi
I could not find a discussion or manual sections about any dependencies for the following:

There are 2 separate GPIFII blocks to switch between; one 16bit, the other 32 bit.
Each GPIF has a different pibClock.clkDiv and CyFxApplnSetPibDllParameters().


When switching (reloading) GPIFs, do the FX3 USB, DMA, or any other component, need to be torn down first and re-initialized?

Thanks
JN

0 Likes
1 Solution
Hemanth
Moderator
Moderator

Hi JN,

Please refer to AN84868 firmware where IO Matrix is reconfigured.

Before you reconfigure, as done in the application, you need to perform CyU3PGpioDeInit(), CyU3PSpiDeInit(), CyU3PPibDeInit() and all the blocks you have used in your old configuration before moving to new configuration.

In the above app note CyFxSwitchtoslFifo() re-configures the IOMatrix

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
16 Replies
Hemanth
Moderator
Moderator

Hi,

In IOMatrix configuration, is the variable io_cfg.isDQ32Bit set to true from the start? Or do you want to change this also?

From your description, I think your requirement is to call CyU3PPibInit() and CyU3PGpifLoad() in run time with different configuration, Is that correct?

Regards,

Hemanth

Hemanth
0 Likes
JoNe_4646056
New Contributor II

Hemanth

Yes, need to change io_cfg.isDQ32Bit also.

At bootup, io_cfg.isDQ32Bit is set false in main just after CyU3PDeviceInit and CyU3PDeviceCacheControl, but before CyU3PKernelEntry.

CyFxApplicationDefine creates thread that sets pibClock.clkDiv in CyU3PPibInit, and CyFxApplnSetPibDllParameters.

-- before CyU3PGpifLoad( &Cfg16).

Upon some activity or a vendor request, need to CyU3PGpifLoad( &Cfg32).

-- This 32bit config requires io_cfg.isDQ32Bit set True, but also resets diff values for pibClock.clkDiv and CyFxApplnSetPibDllParameters.

NOTE: FX3 application can then switch between these 2 configs upon host request.

0 Likes
Hemanth
Moderator
Moderator

Hi JN,

Please refer to AN84868 firmware where IO Matrix is reconfigured.

Before you reconfigure, as done in the application, you need to perform CyU3PGpioDeInit(), CyU3PSpiDeInit(), CyU3PPibDeInit() and all the blocks you have used in your old configuration before moving to new configuration.

In the above app note CyFxSwitchtoslFifo() re-configures the IOMatrix

Regards,

Hemanth

Hemanth

View solution in original post

0 Likes
JoNe_4646056
New Contributor II

Hemanth

Nice! I will incorporate AN84868 reference and your comments in our code and update status within a day or two.

Thanks.
John

0 Likes
JoNe_4646056
New Contributor II

Hermanth,
With code changes, can now switch from gpif16 to gpif32. Will be testing 32->16 shortly.

Is there a mechanism to mask out (ignore) a GPIO via the APIs?
This is since our HW design uses some GPIOs, so have omitted CyU3PGpioDeInit (for now) during GPIF switch. We're testing those GPIOs during switch to determine if this is an issue or not.

Comments/feedback on AN84868:

In the makefile, looks like the second .h is not required (?)
     $(C_OBJECT) : %.o : %.c cyfxslfifosync.h cyfxgpif_syncsf.h<----****

Thanks
John



0 Likes
Hemanth
Moderator
Moderator

Hi John,

I did not get what you meant by Is there a mechanism to mask out (ignore) a GPIO via the APIs?

can you please give more details.

Thank you for your feedback about the header file. We will look into it.

Regards,

Hemanth

Hemanth
0 Likes
JoNe_4646056
New Contributor II

Hemanth
The GPIO mask question is because we use some GPIOs for secondary circuits that need to be isolated while the GPIF related GPIOs are deinit/int.

I was hoping that each GPIO had an enable; if so, the API/drivers would not touch (mask out) the specific non-GPIF GPIOs we use.

I'm guessing though that the GPIO H/W block has a single enable line/bit control!

Thanks

John

0 Likes
JoNe_4646056
New Contributor II

Further testing shows some discrepancy between ControlCenter (CC) on Linux vs Windows?


Using either a Linux built (OR a Win10 built) FX3 image:

With Linux CC, after a gpif switch is initiated via a VendorRequest, subsequent USB transfers occur with no issue.
With Win10 CC, the USB transfers fail.

Turns out in Win10, ResetPipe needed to invoked after the gpif switch to enable further USB transfers.
In this scenario, I assume Linux CC autodetects an error condition(??) and invokes ResetPipe by default?

What exactly does the ResetPipe invoke in the FX3 code? .....

Thx
John

----------------
Note that my original question assumed that the 16bit/32bit GPIF switch would affect DMA/USB etc. Again, the GPIF switch seems fine without reinitializing the GPIF block (as noted) - we still have to test the non-GPIF GPIOs during a switch.

0 Likes
Hemanth
Moderator
Moderator

Hi John,

ResetPipe would send out CLEAR_FEATURE request to the selected endpoint.

1. So, as of now, you have not performed GpioDeinit. Is that true?

2. Can you please let me know why io_cfg.isDQ32Bit is not set to true in the beginning? Are you using both UART and SPI in the beginning and later when you switch to 32-bit GPIF, you are using only one of UART or SPI?

The reason for asking this is to know if it is really necessary in your case to re-configure IOMatrix.

Regards,

Hemanth

Hemanth
0 Likes
JoNe_4646056
New Contributor II

Thx for confirming ResetPipe's action.
A followup (as I'm not a USB expert), is whether the CLEAR_FEATURE CallBack is invoked without any other processing in the FX3 library ? If so, then rather than using a HOST CLEAR_FEATURE, this could perhaps be reset within a VendorRequest Callback/Application thread (?).

1. Yes. the code executes OK without doing a GpioDeinit, but requires a RESET/CLEAR.
-- We still have to debug/scope the other non-GPIF GPIOs we're using.

2. Yes io_cfg.isDQ32Bit = FALSE at boot in 16bit (SPI) mode; no UART.
-- FX3 then switches to 32b mode (no SPI or UART).

-- FX3 will/can later switch n times between 16b and 32b with Vendor Requests.
Each switch disables GPIF, stops App, CyU3PPibDeInit(), CyU3PDeviceConfigureIOMatrix, CyU3PPibInit, CyFxApplnSetPibDllParameters, and CyU3PGpifLoad (16 or 32) before restarting the GpifSM.

0 Likes
Hemanth
Moderator
Moderator

Hi John,

 

Yes. You can do the handling that is done when CLEAR_FEATURE is obtained in the vendor command also.

 

Can you please let me know what is the problem if you do below:

1. In the beginning when IOMatrix is configured choose 32 bit GPIF; Make SPI true.

*correction - (please note that this point #1 is wrong. SPI cannot be used when GPIF is configured for 32 bit. The same is mentioned in following posts.)

2. When you load GPIF state machine, make sure that you have chosen 16 bit bus width (in the configuration tool)

3. When you want to switch to 32 bit bus, you can disable gpif by calling CyU3PGpifDisable.

4. perform app stop (refer to AN75779)

5. Reload gpif configuration with 32 bit

6. perform app start

 

In this way you can avoid reconfiguring IOMatrix.

 

Regards,

Hemanth

Hemanth
0 Likes
JoNe_4646056
New Contributor II



Apologize for the long delay as I was not @work.

I will followup within the week on your suggestion above to avoid reconfiguring IOMatrix.

Thanks.
John

0 Likes
JoNe_4646056
New Contributor II

,

Thanks for the offline help. I am making some changes and testing now.

WRT io_cfg.isDQ32Bit = CyTrue and io_cfg.useSpi = CyTrue, this means that SPI read/write is available whether a GPIF16 or GPIF32 is loaded?

If so, this would be contrary to the FX3 docs which state SPI is not availabe in DQ32 bit mode - perhaps a subtlety in wording though...(?!)

0 Likes
Hemanth
Moderator
Moderator

You are right. My apologies. At the start if you use 32 bit GPIF, you cannot use SPI.

Regards,

Hemanth
0 Likes
Hemanth
Moderator
Moderator

Hi John,

After boot, when the firmware starts running, if you need to use SPI then you will have to configure GPIF to 16 bit mode. After you finish using SPI, to use 32 bit GPIF, you will have to reconfigure IOMatrix as discussed before.

Regards,

Hemanth
0 Likes
JoNe_4646056
New Contributor II

Hemanth,
Thanks again for following up. It is now running IOCFG.16/SPI at boot and can switch between this and IOCFG.32/noSPI upon request. Had to make a few subtle tweaks to ensure GPIOs and SPI were working in between modes.

This is precisely what we require; can close this thread!

Cheers
John

0 Likes