- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hemanth
Nice! I will incorporate AN84868 reference and your comments in our code and update status within a day or two.
Thanks.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hemanth
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...(?!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are right. My apologies. At the start if you use 32 bit GPIF, you cannot use SPI.
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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