Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Question:Why does the CYU3P_GPIF_ERR_INVALID_STATE GPIF error occur in FX3 SDK?
Answer:The GPIF error CYU3P_GPIF_ERR_INVALID_STATE occurs...
Question: Why does the CYU3P_GPIF_ERR_INVALID_STATE GPIF error occur in FX3 SDK?
Answer: The GPIF error CYU3P_GPIF_ERR_INVALID_STATE occurs when the state machine reaches an invalid state. An invalid state is a state that is not defined the .h file generated by the GPIF II designer tool. Mostly, this happens when mirror states are used in the state machine. To know more about mirror states, see section 4.5 – GPIF II constraints of the GPIF Designer User Guide (gpif2_designer_userguide.pdf). This document is available with the FX3 SDK and can be found in the following location after installing the SDK: C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\doc\GPIFII_Designer.
When mirror states are used in the state machine, the state numbers of all mirror states associated with a state will not be defined in the .h file generated by the GPIF II designer tool. So, in a state machine that makes use of mirror states, if at any point in time the state machine reaches any mirror state, there are chances for the GPIF error CYU3P_GPIF_ERR_INVALID_STATE to be triggered. This will not affect the functionality of the state machine.
Another possible reason for the GPIF error CYU3P_GPIF_ERR_INVALID_STATE is also associated with the use of mirror states. Figure 1 illustrates the reason with the example of Slave FIFO state machine provided with AN65974.
Figure 1. Slave FIFO State Machine
The slave FIFO state machine in Figure 1 uses SLWR and PKEND for identifying mirror states. While building the state machine, the GPIF II designer warns that SLWR and PKEND are removed from the outgoing transition equations from the state IDLE and the state DSS_STATE. If SLWR and PKEND are removed from the outgoing transition equations from the IDLE state, then the following are obtained:
This means that the transition equation from the IDLE state and its mirror states can be either (!SLCS & !SLRD & !SLOE) or (!SLCS and SLRD).
Now, assume that the DSS_STATE is not used in the state machine. If you initiate a read, by first asserting SLCS and then asserting SLRD in the next clock cycle, it might cause a problem. The transition equation (!SLCS & SLRD) will be matched in the first clock cycle and the state machine will transition to an INVALID state. This is because for a read operation, (WR,PKEND) will be (1,1). When (WR,PKEND) = (1,1), the state machine can jump to a valid state only if the transition equation is !SLCS & !SLRD & !SLOE. Since this is not satisfied, the state machine will jump to an INVALID state.
The only way to avoid this problem is to place a valid state in the location matching the "!SLCS & SLRD" equation when (WR,PKEND) = (1,1). This is the DSS_STATE state in the state machine. If this DSS_STATE state is not present in the state machine, it will trigger the GPIF error CYU3P_GPIF_ERR_INVALID_STATE.
So, while developing a custom state machine that makes use of mirror states make sure that the state machine can transition to a valid state for any combination of inputs to avoid CYU3P_GPIF_ERR_INVALID_STATE. If required, a valid state (like DSS_State in AN65974) may be used.
This is just an example firmware to demonstrate the Auto channel where SPI is the producer. This has to be modified according to the actual use cases.
This example communicates with SPI Flash like FX3 SDK example.
Only the channel where SPI is the producer is made Auto in the attached firmware. The channel which has SPI as the consumer remains Manual out.
Testing procedure is as follows:
Program the attached firmware into RAM.
Issue 0xC3 vendor command with wLength = 0x200, wIndex = 0x0000, wValue = 0x0000. Zero Length Packet is returned in the data phase of the control transfer as the actual read out data from SPI is sent to the Bulk IN endpoint.
Perform IN transfer on Bulk IN endpoint, where the Flash data can be obtained.
With the attached firmware, reading data length(wLength) > 0x200 is not supported as the Auto channel has only one buffer of size 0x200. The functionality when there are multiple buffers in the Auto channel with SPI as the producer is not in the scope of present discussion.
Referto the attached firmware, only when the 0x200 bytes are read out of the Bulk IN endpoint by the USB Host. This event CY_U3P_DMA_CB_XFER_CPLT is received in the DMA callback.
The CyU3PDebugPrint API can be used to send debug messages to the host over the USB-CDC interface instead of using a dedicated onboard UART-USB bridge device. To do this, the following changes are made to the AN75779 firmware.
Added a CDC interface to Hi-Speed and SuperSpeed configuration descriptors in cyfxuvcdscr.c.
Created an RTOS thread (cdcThread).
Added CDC class request handling to CyFxUVCApplnUSBSetupCB().
Defined the DebugInit() function, which does the following:
a. Configure the endpoints required for the CDC interface.
b. Call CyU3PDebugInit() by passing the USB consumer socket as argument. Doing this allows the use of the CyU3PDebugPrint API function for sending debug messages over the CDC interface.
This function is called when the SET_CONFIGURATION event occurs in CyFxUVCApplnUSBEventCB().
When the firmware with these changes is programmed to the FX3 device, the following devices get enumerated in the host which can be seen in Device Manager as follows:
The following debug messages appear in the terminal:
The message “cdc-debug-enabled” appears because of the following code in the firmware. You can change this according to your application.
The UART block is initialized in this project, but not used.
If data from the USB Bulk-IN end point of the CDC interface (EP5 in this project) must be sent to the UART block of FX3, enable the ENABLE_CDC_USB_TO_UART_CHANNEL macro in uvc.h. Doing so will configure the USB-to-UART Auto DMA channel.