cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

aranin
New Contributor

I have a USB peripheral device that utilizes the FX3's GPIF,  USB, I2C, SPI, GPIO, and UART.  The FX3 needs to always have USB, I2C, and GPIO's functional.  In 32-bit DQ GPIF,  the UART is enabled, but the SPI is disabled.  On the other hand, in 16-bit DQ GPIF, the UART is disabled, but SPI is enabled. 

I need to be able to switch back and forth between 16 and 32-bit GPIF during runtime.  What are the steps I need to accomplish this runtime reconfiguration?  I have read that I, at least, need to do GpifDisable(...) and then GpifLoad(...) with the proper GPIF settings.  By doing this, would the other modules (USB, I2C, GPIO, UART, etc.) be affected, and need to be reinitialized during the GPIF reconfiguration?

 

0 Likes
1 Solution
AliAsgar
Moderator
Moderator

Hi,

USB re enumeration is not required when switching between 16/32-bit GPIF.

The sequence of steps that need to be followed for switching are:

1. GpifDisable()
2. De initialize all the peripheral blocks.
3. Reconfigure IO Matrix.
4. Initialize the respective peripheral blocks.
5. New GpifLoad().

Best Regards,
AliAsgar

View solution in original post

0 Likes
10 Replies
AliAsgar
Moderator
Moderator
0 Likes
aranin
New Contributor

On that thread, the poster mentioned steps that were tried, and the moderator suggested some steps also.  Which steps actually made it work? 

0 Likes
aranin
New Contributor

Thanks for the quick reply.  I will compare the steps mentioned in that thread to what I have.

However, I am still not clear on what happens to the USB side of things.  That thread mentions a CLEAR_FEATURE event, but I'm not clear on how that is triggered.  My device uses the GPIF to directly transfer data between USB and an on-board component.  Does the USB interface need to be re-initialized and a re-enumeration with the host is necessary when switching between 16/32-bit GPIF?  

0 Likes
AliAsgar
Moderator
Moderator

Hi,

USB re enumeration is not required when switching between 16/32-bit GPIF.

The sequence of steps that need to be followed for switching are:

1. GpifDisable()
2. De initialize all the peripheral blocks.
3. Reconfigure IO Matrix.
4. Initialize the respective peripheral blocks.
5. New GpifLoad().

Best Regards,
AliAsgar

View solution in original post

0 Likes
aranin
New Contributor

The issue I am seeing is that during this 16/32-bit GPIF transition, the FX3 seems to hang.  I tried stepping through it using a SEGGER J-Link debugger, and I see that it gets stuck during the GpifDisable().  And, I do not see GpifDisable() being called in the AN84868 example.

When you say to deinitialize all peripheral blocks, do you mean like the following when going from 32 to 16 bit?

GpifDisable();

// de-initialize peripherals
CyU3PDebugDeInit();
CyU3PUartDeInit();
CyU3PGpioDeInit();
CyU3PI2cDeInit();
CyU3PPibDeInit();

...
CyU3PDeviceConfigureIOMatrix(...);
...

// Initialize peripherals that were de-initialized earlier
CyU3PPibInit(...);
CyFxI2cInit();
CyU3PGpioInit(...);

// use SPI in 16-bit GPIF
CyFxSpiInit();

// Reconfigure GPIF
CyU3PGpifLoad(...);
CyU3PGpifSocketConfigure(...);
CyU3PGpifSMStart(...);

But, it seems odd to me that the peripherals are initialized before the GpifLoad().  Maybe I just don't fully understand what occurs in a GpifLoad().  Anyway, would each GPIF reconfiguration require reinitialization of associated DMA and USB endpoints?  I have the 32-bit GPIF using a similar slave FIFO as in the AN84868 example.

0 Likes
AliAsgar
Moderator
Moderator

Hi,

1. Could you get the return status of the CyU3PGpifDisable(..) API when FX3 hangs?

2. Yes, the peripheral blocks needs to be de initialized in the same manner which you have pointed out.

3. Peripherals can be initialized after GpifLoad(..) API as well.

4. GPIF Reconfiguration wouldn't require re initialization of associated DMA and USB endpoints.

Best Regards,
AliAsgar

0 Likes
aranin
New Contributor

1.  The CyU3PGpifDisable does not have a return value:

extern void
CyU3PGpifDisable (
CyBool_t forceReload /**< Whether a GPIF re-configuration is to be forced. */
);

0 Likes
AliAsgar
Moderator
Moderator

Hi,

Could you share your firmware project, for us to reproduce the issue at our end?

Best Regards,
AliAsgar

0 Likes
aranin
New Contributor

It seems I was able to get it to a working state, but I do not really understand how, so I am still unsure if this is stable.  Perhaps you can help explain why the things I changed matter:

  1. I removed the PibDeinit, PibInit during the Gpif bus width switch. I also removed GpifSocketConfigure after the bus width switch.
  2. I added a time delay after the last 32-bit Gpif transaction before switching to 16-bit Gpif.

 

0 Likes
AliAsgar
Moderator
Moderator

Hi,

What parameter is being passed for the CyU3PGpifDisable() API?

Best Regards,
AliAsgar

0 Likes